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]

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
>