Re: [stack] Re: Concatenative macros?

stevan apter <[email protected]> wrote:
> From: "William Tanksley, Jr" <[email protected]>
> > What might be messing things up is how you treat the [A B] term in the
> > result of 'q'. In this quotation, [A] is [], which means that A must
> > be nothing. It's kind of (severely) wierd, but that's how it works.
> > Does your interpreter act that way?

> it does now.  that wasn't at all clear (to me) from the description of 'q'.

>     [B] [A] q == [[B]] [A B]

> shouldn't that be
>     [B] [A] q == [[B]] [A B] if A is not []
>                  [[B]] B if A is []
> ?

This is one of the things that confuses me about this notation -- but
it's something you have to learn. The reason it's confusing to us is
that it's a purely functional notation, and we're used to thinking
procedurally. You're especially in danger of that, since you're using
a concrete implementation in order to learn about it.

In this case, we think procedurally when we use the word "dequote" to
mean "execute now". What it actually means is "insert the semantics
that are quoted inside this list directly into this context."

I'm taking a long time to get to the point. Let me take a break to
give an example.

>     [B] [A] q == [[B]] [A B] if A is not []
>                  [[B]] B if A is []

Well, first, the second part is a typo -- you probably meant to type
"[[B]] [B]". Second, though, and this is the important part, in this
notation the term "A" doesn't mean "the top item on the stack". It
means "the semantics which are quoted inside the top item on the
stack."

> did i read right past that in brent's original explanation?
>   O["";"[1][0]q"]
> [[1]][[0][1]]
>   O["";"[1][]q"]
> [[1]][1]
>   O["";"[][0]q"]
> [[]][[0][]]

I can't read this notation; sorry.

> do i have this right, or should B = [] produce analogous
> behavior?

Precisely so -- "B" means "the semantics quoted inside the second item
on the stack". If [B] == [], that means there are no semantics quoted
inside the second item on the stack.

So these things are not a special case; they're normal behavior.

> in any case, kudos to both you and brent.  this is fascinating.

Thank you -- and a HUGE thank you to Brent, who's at last made this
all make sense to me. This is exciting to me, since I've been puzzled
by it for so long.

I've decided (tentatively) that my next goal is to build a basis in
which swap is easier to express. I don't think that'll be the last
basis I construct :-), but I'm just not happy with the extreme
imbalance between how easy it is to nip and how hard it is to swap.

I know there will always be tradeoffs; but I want to learn how to make
them wisely. I have a very strong sense that some of these bases are
FAR easier to work with than others, so I'm confident that there's
much room for improvement.

> > > i've posted an interpreter for 01 at:
> > >     http://www.nsl.com/k/01.k

I wrote a Python interpreter, although I didn't even try to run it, so
it's probably severely broken. (My purpose was to explain this to a
fellow programmer who doesn't know anything about concatenativity or
flatness or mathematics; I succeeded, since he wrote back with a bunch
of derivations.) Does anyone want to see it? It's not that many lines
long.

-Billy