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

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

> Manfred Von Thun <[email protected] <mailto:m.vonthun%40latrobe.edu.au>
> > wrote:
> 
[..]
I could not comment on the lean flat language experiment

> Such a language could indeed be flat and concatenative; but please
> consider that the semantics of the language would be more complex
> because words would have to consider their effect on the foyers, not
> merely on the stack.

to anticipate: the L that I am discussing has a stack of foyers, starting
with
a stack of two empty foyers. What a symbol does depends on the stack that
it finds, and in many cases this means just the content of the top foyer.
> 
>> > At certain times a queue in a foyer gets sent elsewhere and the foyer is
>> > destroyed. A foyer is created by the special item ³[³, and destroyed by the
>> > special item ³]².  I also need a notation for describing foyers: a newly
>> > created empty foyer is written <>, an after a ³dup² item arrives the foyer
>> > is written <dup>, after a ³*² item arrives it is written <dup *>. But a
>> > foyer is not a list, in fact a foyer can contain lists. Foyers cannot be
>> > nested, but there is a stack of foyers: I shall write this stack with the
>> > topmost item on the right.  When a foyer is destroyed by ³]², the contained
>> > queue is sent to the foyer below as a list. Finally, a ³.² will use the
>> > contents of the top foyer as a program to execute by using foyer below
>> > as a stack.
> 
> A nice description. This language also changes the nature of the "."
> operator, so it's now a kind of an 'i' operator as well as a syntactic
> delimiter.

³.² is now a full blown operator, and indeed it resembles ³i² somewhat. But
there
is a difference: ³i² executes a quotation that it expects on top of a stack
and
executes it on the remainder of the stack. By contrast, ³.² executes the
content
of the current foyer using the foyer below as a stack. Perhaps ³.² is more
like
³infra², but even that isn¹t quite right.

>> > To recapitulate: everything gets appended to the top foyer, except for
>> > the three special commands ³[³  ³]² and ³.² ,  as follows:
>> > ³[³ starts a new foyer
>> > ³]² pops the top foyer and appends its contents as a list to the foyer
>> > below.
>> > ³.² pops top foyer and executes contents on foyer below.
> 
> Interesting... So a way to execute an anonymous function would be to
> begin it with "[" and end it with ".".
> 
Indeed. In fact, assuming that we have otherwise balanced parentheses inside
³- - -², the following should be equivalent:

>> [ - - -  .
>> [ - - - ] i .
>> 
>> > 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.

>> > 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?²


>  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? But you can do four things with foyers.
1. fill then up with things like 42, +, map and so on.
2. start a new one with ³[³.
3. execute them on the foyer below, by ³.²
4. append their contents as a list to the foyer below, by ³]².

> The only thing
> you can do is write functions of which parts will inevitably be
> ignored, without receiving a warning. You can't perform a "[" or "]"
> at runtime (for example, inside a loop).
> 
There is no separate runtime as opposed to parsetime. ³[³ and ³]² never get
inside a foyer. The fact that lists inside a foyer are written <111 [22 33]
444> are written using ³[³ and ³]² does no mean they are in the foyer. This
foyer just contains three elements: two numbers and between them a list of
two numbers.
> 
> 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.
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.
> 
> 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?
> 
> 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.
> 
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.
> 
> Any way you put this, flatness is not in the eye of the beholder.
> Flatness is a language feature which Joy does not currently possess.
> If you want to add it you clearly can; it looks like it would be
> simple for you to do. The cost for Joy would be a syntax that accepts
> many odd programs, which seems to me to be a high price to pay; to
> avoid this being a useless feature, you'd have to clearly define the
> runtime behavior of foyers, and provide functions to manipulate them.
> 
But the odd programs would be just those that leave more than one foyer
below. That is no more odd than an ordinary Joy program which leaves
one or more quotationson the stack, such as [11 22 +] or [cons 42 +],
whether the are executable or not.
> 
Repeat: the runtime is all there is. There are the four ways of manipulating
foyers. But why does one need new functions?
> 
>> > But one could invent an extension L++ which allows other things to be done
>> > to foyers.
> 
> This would make the change possibly useful.
> 
The way to manipulate the contents of foyers should be obvious: apart from
filling foyers (from the ³end², if you like), an incoming ³.² calls the
content of the
top foyer to be executed using the foyer below as a stack. That is always
the same.
The whole of Joy machinery is available to manipulate the contents of
foyers.
> 
>> > Conjecture -- 1: Joy can be seen as a flat language, and could be
>> programmed
>> > that way if one really wanted to.
> 
> Not as it stands. But such a version could be constructed, yes.
> 
>> > But 2: But everything that can be done  by
>> > programming in the flat version can equally well be done with the plain
>> > version.
> 
> That's just because foyers aren't first-class.
> 
See earlier comments

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

  - Manfred



[Non-text portions of this message have been removed]