Re: [stack] Re: Concatenative macros?

[email protected] wrote on 02/09/2007 10:25:56 AM:

> stevan apter <[email protected]> wrote:
[:]
>
> > [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.
[:]
>
> 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.

my confusion was purely notational:  i didn't realize that "A B"
meant (what i would write as) "A^B", although the left-hand-side of
the rule should have clued me in.

i notice that robbert also favors a rewrite-rule style for his
exposition of enchilada.  and he too is always correcting me on
this matter!

>
> > 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.

yes, i find his contributions uniquely valuable, indispensable to
understanding this terrain.  thank you brent.

>
> 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.

onward.  i'll be with the baggage, in the rear.

>
> > > > 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.

yes, by all means.

as i mentioned to you privately a few days ago, i wrote the interpreter
as a preliminary step to experimenting with a genetic algorithm (to find
programs.)  as you pointed out at the beginning of this discussion,
programs constructed in a flat, two-element language seem tailor-made
for recombination operations.

01.k contains inner and outer interpreters.  the inner interpreter
evaluates and produces binary sequences.  the outer interpreter takes
strings using a vocabulary (e.g. zap, i, unit, &c.), deconstructs them
into binary sequences, invokes the inner interpreter, then constructs
strings in the vocabulary from the result.

>
> -Billy
>