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

"William Tanksley, Jr" <[email protected]>
Newsgroups gmane.comp.lang.concatenative
Message-ID <[email protected]>
Manfred Von Thun <[email protected]> wrote:
> Cancel the cancellation. The previous cancellation was for a very tentative
> pre-Prolog draft of something about typing Joy. My mailer claims it was
> sent to concatenative, and I did receive it back, but I did not see it when
> I looked at the group from Google. I really don¹t know what I have done
> wrong.

I'm glad to hear it -- I thought your post was interesting, and I
couldn't recall having seen it before.

Thanks for taking the opportunity to clean it up.

> The problem seems to be how to handle apparent non-flatness due to
> quotations/lists, which can be nested. I need to introduce the notion of a
> waiting room, or ante-room, or briefly, a foyer. This is where incoming
> items form a queue (perhaps similar to Stevan's Y queue in his XY language).

Well, by some definitions the Y queue makes a language
non-concatenative (or more accurately, programs that manipulate the Y
queue might not be concatenative).

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.

In one of my experiments with my 1-bit flat language I added two extra
symbols (thus making a 4-bit language), and had the extra symbols
serve to append an operator onto the list on the stack (I also
redefined the 0 operator to place only an empty list on the stack).
This works much like what you've described, except that foyers are the
same as lists.

So for example:

0 == []
[B] [A] 1 == A
[A] 2 == [A k]
[A] 3 == [A q]

The resulting language wasn't really any shorter than the original
1-bit language for the derivations I tried, so I set it aside. It is a
bit simpler to understand at a low level, I think, but that advantage
doesn't seem to extend to shorter code at a high level, so I'm not as
happy with it as I hoped.

> 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.

> 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 ".".

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

> 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. 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. 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).

One thing I'm not clear on, though. Are these foyers available at
runtime? 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:

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?

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 one could invent an extension L++ which allows other things to be done
> to foyers.

This would make the change possibly useful.

> 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.

>   - Manfred

-Billy
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.