Re: [stack] S-K Construction of Dip?

Manfred Von Thun <[email protected]> wrote:

Thank you for the prompt and clear answers. To cut to the chase: I
agree that the language "L" is both flat and concatenative, and that L
is not enormously different from Joy.

However...

My first reaction was that although I confess that I have researched
flatness for its own sake, I suspect that there are higher principles
in language design than perfect flatness, and I believe that L's
design compromises some of them. I don't think that's a bad thing --
but I did believe that unless I point out the problems, the obvious
conclusion would be that flatness was the cause of those problems,
rather than the design choices that allowed flatness.

I'm not certain that I was right... thanks to your explanations, I
might see the benefit to L.

> On 29/3/07 3:05 AM, "William Tanksley, Jr" <[email protected]> wrote:

> >> > Is L flat enough? It is a language from stacks to stacks, using
> >> > concatenative notation.

> > I don't know. You haven't specified the runtime semantics of foyers;
> > you've only explained what happens inside the parser. Are the foyers
> > preserved across definitions?

> There is no parser. There is a lexer/tokeniser. Then there is the runtime.
> At runtime a stack of foyers gets processed. How it is processed depends on
> what it receives from the lexer. The initial stack has two empty foyers. A
> conventional Joy program running L ends up with a foyer that is just like
> the stack that running that program under Joy would end up with.

An excellent answer. You later detail that the foyers exist at
runtime, which means that your language provides the basic support
needed to be flat.

Good job; I now clearly see that L is flat.

> >> > One consequence from all this is that Joy is or is not a flat language,
> >> > depending on what one considers the language to be. Presumably the same
> >> > could be said of just about any language which has nesting of one kind
> >> > or another. To express it as a slogan: flatness is in the eye of the
> >> > beholder.

> > In spite of your interpretation, Joy (as it stands) is not flat; if
> > you unbalance the foyers, the parser will barf.

> I don¹t know what you mean by an unbalanced foyer. If you mean something
> like unbalanced parentheses, then you should get the warning in this L
> (whereas it
> would be an errorr in Joy):
> ³Incomplete program? more than one foyer remaining. See top foyer?²

Again, I was talking about Joy. Joy is not flat; it doesn't depend on
your perspective. L _is_ flat; again, it doesn't depend on your
perspective.

Why didn't I like L -- in spite of its very manifest cleverness?

I think my shortest answer would be "Occam's razor". To quote:
"entities should not be multiplied beyond necessity." L introduces a
new entity, the "foyer", which serves no purpose but to allow the
designer to claim flatness. If the foyer also allowed some terseness
or expressiveness, or otherwise demonstrated a result in language
design, I would be much more impressed.

I'm going to try to think of one.

> >  A language without
> > that error message but with the interpretation otherwise the same
> > would be flat -- but such a language would be different from Joy.

> > How different? And would the difference be useful?

> > I'm afraid that from what I can see the differences wouldn't be
> > useful. The problem is that in Joy foyers aren't a first-class
> > construct; you can't do anything with them at runtime.

> Normally ³first class² means ³can be passed as a parameter or can be
> returned as a value. Indeed, but how does this count against being
> concatenative or being flat?

I have to admit that foyers can be returned as values -- your answers
have made that clear. The ability to pass them as parameters would be
a nice addition, and I suspect would not be a difficult thing to add
-- I imagine that just as Forth has words to preserve a value on the
return stack, JoyL would have words to 'dip' into the foyers.

My imagination suggests that your new language would have more
expressive power than Joy alone. In fact, my imagination suggests that
such a language might be as purely functional, concatenative, and
perhaps even as fun to program in as Joy, while being flat as well.

Exciting, if true. Is it?

Clearly, "[" creates a new foyer on the foyer stack, and "]" converts
the top foyer into a quotation nested into the next foyer. I see no
need for any special operators to juggle entries on the foyer stack
(am I wrong?). However, it would make sense to provide a function to
append the item on top of the data stack into the current foyer, and a
function to pop the top foyer onto the data stack and convert it to a
quotation. Without those, foyers can't be manipulated at runtime.

There's one thing that's nagging at me...

GOT IT! As an old Forth hand, I remember the need for IMMEDIATE words:
functions that execute when the compiler encounters them, rather than
being compiled for later execution. The problem is that "[", "]", and
"." are immediate words... They don't act like all the other functions
in L.

All the other functions in L get appended onto the topmost foyer on
the f-stack as soon as the compiler encounters them. Not those! They
do something else.

Does this make your language non-flat? Definitely NOT. Those words are
special, but they can be made to fit by describing the functions of
all other words as "this function appends the operation denoted by its
name onto the topmost foyer". (This is similar to the way we describe
concatenative languages as denoting function composition -- in
practical we don't think of it that way, we merely get the benefits.)

I'm not going to suggest (at this point) that you do what Forth did,
and make it possible to mark ANY word "immediate", so that it's
possible to make your own IMMEDIATE words to extend the compiler. I
actually think that wasn't a good thing, and even Chuck Moore doesn't
think it should be used often.

But... We should add non-special (runtime) words that perform the
functions of "[", "]", and perhaps "." (the latter can be implemented
in terms of previously explained words).

So we have:

 + "[": syntax, new foyer.
 + "]": syntax, embed foyer.
 + ".": syntax, execute top foyer.
 + "foyer": runtime, new foyer.
 + "embed": runtime, append TOS on top foyer.
 + "quotation": runtime, convert top foyer to quotation on TOS.

I'm not sure that "." is needed. Why was it in there again? Would "."
be the same thing as "quotation i", with no need for special syntax
treatment?

> > One thing I'm not clear on, though. Are these foyers available at
> > runtime?

> Yes, in the L-definition of runtime. This is not your definition, I know.

I think it is my definition as well -- what am I missing?

> But
> L has a right to make its own definition. In L one would define your notion
> of runtime as: executing the content of the topmost foyer using the
> ONLY remaining foyer below as its stack. But the executions of topmost
> foyers would be exactly the same if there are further foyers below.

Nope, that's runtime. We're good.

> > In practical terms: if I split a Joy definition into two
> > parts (cutting in the middle of a quotation), giving each part of the
> > definition its own name, and then I define a function which contains
> > the two parts one after the other, is the resulting definition
> > equivalent to the original? For example:

> Since when does being able to give names to the parts have anything to
> do with cuttability or flatness?

It doesn't -- names help clarify things. I assume syntax to assign
names for the sake of clarity. If asked the same question about my 01
language, I would assume the same thing.

> >DEFINE
> >  Csucc   ==  [dup [i] dip] dip i.
> >DEFINE
> >  CsuccA == [dup [i];
> >  CsuccB ==  dip] dip i;
> >  CsuccC == CsuccA CsuccB.

> > Is CsuccC exactly the same as Csucc? Would it still be the same if
> > CsuccC were defined in a DEFINE block apart from CsuccA or CsuccB?

> I have not said anything about definitions in L, and your example does
> show that if L is to be of interest at all, then L needs to use a different
> style of definitions. Thank you.

Interesting. How would they differ?

> For a while I thought that your example (just the cutting into three bits)
> even shows that
> concatenativity is ruined. But no, the three bits each compute functions
> from stacks of foyers to stacks of foyers, and the concatenation of the bits
> computes the composition of what the bits compute. So no worry here.

Great -- that (together with the other things you've explained) gives
sufficient evidence to me that the result is both concatenative and
flat.

> Thanks for the discussion, Billy. I hope I have cleared up a few things.

You certainly did! I hope I make more sense now that we're on the same page.

>   - Manfred

-Billy