Re: [stack] Concatenative macros?

----- Original Message ----- 
From: <[email protected]>
To: <[email protected]>
Sent: Wednesday, January 10, 2007 3:29 PM
Subject: Re: [stack] Concatenative macros?


> 
> 
> i think i've formulated a version which captures your requirements.
> since setting down the rules is more difficult than grasping the
> notation by way of examples, let me do that first:
> 
>       car         [aB]-a
>       cdr         [aB]-B
> 
> B is the rest of the list [a ...].  that is, B is [...].
> 
>       cons        aB-[aB]
> 
> B on the left matches a list.  on the right [aB] is the list
> with a as the first element, and B as the remaining elements.
> 
> on either side, a list may contain at most one upper-case letter:
> 
>       [aBc]

correction:  a list may contain any number of non-contiguous upper-
case letter, e.g.

        [aBcDe]

is fine, but

        [aBCd]

is not.  

> 
> a is the first, c is the last, [B] is [aBc] without a, c.
> 
>       uncons      [aB]-aB
> 
>       i           A-a
> 
> A matches a list, a is A i.
> 
>       dip         aB-ba
> 
> so then what do the following shuffles mean?
> 
>       a-A
>       [aB]-[ab]
> 
> the first could be quotation; i.e. a-[a].
> 
> the second could be disquotation without execution:
> 
>       [2 [3 +]] [aB]-[ab] -> [2 3 +]
> 
> i don't see any problem extending the notation to handle nested
> lists on either side.
> 
> but this is just off the top of my head, and i might have
> overlooked some lurking inconsistency.
> 
> [email protected] wrote on 01/10/2007 11:21:19 AM:
> 
> > stevan apter <[email protected]> wrote:
> > > > stevan apter <[email protected]> wrote:
> > > > > between you and john, i now understand the point about "improper
> > > > > lists".
> >
> > > > > i think the two notations can be made equivalent by adding a
> special
> > > > > symbol to each.
> >
> > From the rest of your message, it's clear that you didn't want support
> > for "improper lists"; what you wanted was the ability to get the last
> > item out of a list without having to execute anything. A fine
> > ambition. My notation (so far) doesn't support that, and I can see why
> > you'd want it. Furthermore, it's a natural feature within any notation
> > that allows list deconstruction, since such deconstruction naturally
> > carries the exact same risk of error (said error being that the list
> > doesn't have the desired structure).
> >
> > > > > on second thought, maybe you don't need the extra symbol. isn't
> > > > > [ab[]] a pair? (as i said, the "car/cdr/cons" approach to lists
> > > > > isn't the natural way for me think about these things.) if this
> > > > > is the case, then i think i favor your notation.
> >
> > > > Well, actually, [ab[]] (either of our notations) is the same thing as
> > > > [aB] (in your notation) and [ab] in mine.
> >
> > > no, that isn't actually true. in my notation [ab[]] is a list of three
> > > items: a, b, and []. [ab] in your notation is equivalent to [aB] in
> > > mine.
> >
> > No, you're right; my notation doesn't define an input meaning for
> > [ab[]], because I didn't consider what happens to nested lists. That's
> > because I didn't want to deal with list deconstruction, so I didn't
> > put any thought into it. Further instances of not putting thought into
> > things will be followed by further instances of putting my foot into
> > my mouth.
> >
> > But this is worth thinking about.
> >
> > I believe that the strengths of our two syntaxes can and should be
> > combined into a single semantics which would scale nicely, so that
> > languages with differing needs can pick the subset that matches their
> > needs and capabilities. Some languages require only shuffling; some
> > require execution; some require list construction; some require list
> > deconstruction into head and tail; and some require full list
> > deconstruction.
> >
> > By the way, I admit grudgingly that some language designs do require
> > lambda forms. I persist in claiming that our mega-shuffle notation
> > need not support that; I would suggest that such languages should
> > borrow syntax from an applicative language, since that class of
> > languages has thoroughly researched the practice (a concatenative
> > language with locals is essentially the same as Haskell interpreting a
> > monad). Fitting lambda support into our notation would simply balloon
> > the notation.
> >
> > Therefore, I choose to limit the features we need to support to
> > shuffling, enlistment, delistment, indexing, and execution. (Here I
> > choose to define "indexing" as accessing elements deeper in the list
> > than the first element, what I earlier called "full list
> > deconstruction".)
> >
> > > if my program expects a two-element list, and wants to operate on
> > > those elements as named entities, then [ab] will pick them off and
> > > make them available to the program. in your case, your program
> > > will use [ab]-aB.
> >
> > Unfortunately, my notation would make it impossible to execute a
> > combinator which happened to be the CDR of a list, since I can only
> > uppercase once. Strike one for my notation.
> >
> > So let me go a bit closer to your notation on the input side, except
> > that 'a' and 'A' are no longer distinct variables. Case is used to
> > control how the input is fetched and how the output is generated.
> >
> > I'm having some trouble defining (in my own head) the meaning of an
> > uppercase letter on the input side. Even in your notation it seems a
> > bit limited. The examples you gave are clear enough, but what happens
> > if an uppercase letter appears in some other place than the tail of a
> > list?
> >
> > Anyhow, it would be a start to define a special meaning for uppercase
> > in the input: it's defined only as the last character in a list
> > pattern, and as in your notation, it means "the rest of the list". On
> > the output side, uppercase would indicate execution, as with my stack
> > shuffle notation.
> >
> > I think that makes all your examples work, although "[aA]-a" doesn't
> > work (it has to be changed to "[aB]-a", since variable names have to
> > be unique regardless of case). Then the definition of cdr becomes
> > "[aB]-b".
> >
> > I'm really not very happy with the fact that uppercase letters on the
> > input side are undefined except at the tail of a list. I've thought of
> > a few meanings, but none of them make me happy and fulfilled :-).
> >
> > I'm considering making upper case in the input side mean "gather as
> > many values as will fit", which might be handy... What do you think?
> > Doing that would change the definition of CDR to "[aB]-[b]", and would
> > allow i to be defined as "[A]-A" (that means get the entire contents
> > of a list and execute each of the atoms in it, first to last). Of
> > course, an uppercase letter outside of a list would still be
> > undefined, so I haven't really completely solved the problem, but at
> > least I've opened a new door (I don't think either of our notations
> > could express the definition of "i" before).
> >
> > -Billy
> > 
> 
>