Re: [stack] Concatenative macros?

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