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