RE: [stack] Re: tree rewriting

wtanksley@bigfoot.com — 2000-05-25 19:14:15

From: Mark van Gulik [mailto:ghoul6@...]
>To which Brent Kerby (iepos@...) replied:
>> You say you're kidding, but you bring up a good point. Using things
>> like "typeSwap", "typeDup", "typePop", and "typeMatchAndPop" seems
>> like a good idea, since it avoids the use of the
>> variable-like primitives
>> "2nd" and "1st".

Keep in mind that what you're doing does *not* avoid "2nd" and "1st"; I
think that's the coolest thing about it. "2nd" and "1st" can be easily
defined in terms of typeDup and typeSwap (and so on).

The people who don't need the power can use 2nd and 1st and explicit
typenames; people who do need the power can use full typebuilding, if they
wish.

Yes, I've come to like this.

>> However, "swap", "dup", and "pop" by themselves is
>> not complete; for, with just those, how could you construct a

>> You'd also need a type "quotation" construct;

>> It is interesting that in this style types are written in the exact
>> same syntax as ordinary programs, using concatenation and
>> quotation ...

>That was fully intentional.

Yes, and it's clearly powerful.

Forth teaches us something similar: that you want to have the same language
available to specify compile-time behavior as is available to specify
runtime behavior.

With this in mind, I propose a semantics clarification: we need a way to
denote "compile-time code", which can optionally act on the type stack and
can be placed anywhere within a definition. In Forth, compile-time code is
always delimited by square braces. Joy uses square braces to indicate
quotations, lists, and trees, so we'll have to use something else if we're
improving Joy and not making a new language -- I suggest curly braces.

: some-add { integer dup 2 types-input }
+
{ integer 1 types-output }
;

Note that there's no need for special type operators; there still is a type
stack, but rather than juggling things around on it, use two primitives ">t"
and "t>" (pronounced "into-tee" and "tee-from") to pop the top typestack
element onto the data stack and vice versa. "types-input" and
"types-output" are defined in terms of these.

Now, just as I chose to define types-input to make my job easier, I could
also define another word, perhaps named "stack(", which would make type
specification simpler for those wishing to use it.

: some-add stack( integer integer -- integer ) + ;

But this is only "syntactic" sugar. (I think syntactic sugar is the most
important part of any language, BTW. ;-)

>Just so you don't have to scan previous posts, the Avail web site is:
> http://www.ericsworld.com/Mark/HTML/Avail.html

Thank you.

-Billy