Re: [stack] Re: Flat concatenative basis (was: Concatenative macros?)

iepos <[email protected]> wrote:
> > I chose a different basis which results in shorter constructions for
> > the primitives we're producing.

> Wow! That's much better. Nice work.

Thanks, but obviously it builds on your work -- you actually know what
you're doing, and you get all the credit for making it make sense.

I suspect that this language is more easily explained than any of the
unlambda-ish competitors. In theory, it might be nice that each
element of the language stands alone, and any substring of any program
can be understood in isolation, and it means exactly the same thing in
context, no matter what the context is.

(In practice, a real language would have to define a data convention,
so there would be a difference between data and code.)

I sent a Python implementation (of your first version of the language)
to a friend who knows Forth but no math (a pure electronic engineer
type), and he responded with a series of derivations (although he
wasn't really interested in the language and in fact some of his
derivations were incorrect, he definitely proved that he understood
it).

> > I think it's universally shorter;

> Well, what exactly do you mean by that? There's certainly one
> combinator which is shorter in my {o,i}, namely "i". But there
> probably aren't too many more :-) Perhaps only finitely many. That
> would be an interesting question ...

That's what I meant, yes. I don't know a precise way of asking the
question; I've seen that type of assertion made in math, but I don't
remember how it was expressed. It's also possible that in that
particular case there's no way to express what I meant (but you know
what I mean).

Anyhow, I found my {01} basis to be far easier to derive things for
than your {oi} basis. I suspect there's a reason for that. I also
found my basis to be very hard to express stack reorderings in, and I
suspect I know a reason for that. I want to see how *good* of a basis
I can possibly construct.

> > I still need to explore the effect of using cake instead of q.

> Well, I can show you that {[] [cake] [k], k} is incomplete (and the
> choice of total dequoter "k" is irrelevant to the following argument,

Very nice. You just saved me a lot of time. And, to boot, gave me a
good example of reasoning. Well,  more accurately, you caused me to
spent my time looking at good reasoning instead of trying to create my
own bad reasoning.

> > I also need to (just as an exercise) express 'dip' and 'swap' in
> > this system.

> If you still want the exercise, close this message now. I also wanted
> the exercise, so I'm going to spoil it below :-)

I tried, I failed. Your path to a solution is more prudent than mine.

> to get dip; but I doubt that this is helpful, because "swap" is
> probably more complicated to construct than "dip". At least, in the

That was my conclusion as well.

I'm still exploring basises (bases? basi?). I know there's no
perfection, only tradeoffs, but I also suspect that some are much
worse than others, and I have no theoretical basis for believing that
I've found the "best".

> - Brent

-Billy