# 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