# three more proposals about Joy

## iepos@tunes.org — 2000-07-01 02:17:49

    Hello folks ...

    The last while, I've been thinking a bit about a few ways I would like

    Joy to be modified. You may or may not like these ideas ...

    1) Design the system so that the user feels free to pile tons of items

       onto the stack (treating it as an array). Modify the "size" primitive

       to tell how many items are on the stack. Add a primitive "wrap"

       that wraps the whole stack up into a list. Make it feasible to

       use "call" ("i") to unwrap a list onto the stack. Modify "map" to

       apply a quotation directly to all the other items on the stack,

       instead of taking a list; thus, one could do

         1 2 3 4 [dup *] map

       and get

         1 4 9 16

       Modify several other list-oriented primitives ("first", "rest", "at",

       "take", and others) to take things directly off the stack instead of

       from lists.

       Rationale: it is simpler; it eliminates the need for many "[]"s and

       related operators which serve no purpose.

    2) Eliminate the ability to do direct introspection on quotations.

       This is actually a consequence of the suggestion in #1;

       "first", "rest", "at", "take", "size" could no longer be used to

       peek into a quotation, since the reformed versions fiddle with items

       directly on the stack instead of in quotations.

       Anyhow, it might be useful for a system to have "reify" word that

       takes a program, and dumps a corresponding bunch of tokens onto

       the stack, or some other representation of the program. A system

       might also want to provide "compile", the complement to "reify";

       this would take a bunch of tokens and transform them into a program

       that can be manipulated with "call", "concat", "cons", and such.

       Rationale: allowing direct introspection of quotations seems to require

       the system to keep track of the exact way a user has constructed

       a quotation; this is bad in many circumstances. For example, imagine

       that the user has pushed "[2 + 3 +]" onto the stack. It would be

       nice if the system could internally rewrite this as "[5 +]". However,

       this would not be permitted if direct introspection is allowed,

       because the user could be relying on the quotation to stay exactly

       as he put it on there, as "[2 + 3 +]". (Okay, that wasn't exactly

       a really good example).

    3) Replace Joy's "==" construct, and its friends, "LIBRA", "HIDE", "IN",

       and "END" with a fully-fledged lambda construct. (Okay, I've already

       mentioned this before).

       Basically, a lambda in my notation looks like "foo\" where "foo"

       is any name, hitherto undefined, that the user wants to use.

       "foo\" can be thought of as a command that means,

          Pop the top item off the stack and call it "foo".

       Thus, if a user has been fiddling with the interactive interpreter,

       and has ended up with an interesting list or other thing on top

       of the stack, so interesting that he wants to give it a name, he

       can say "foo\", and *INSTANTLY* the system will bind the name "foo"

       to the item that was on the stack (which is now popped off).

       If the user becomes tired of that name, he can end the lambda's

       scope by doing "\foo".

       A lambda could also be used for definitions; for instance, one could

       define "swapd" by doing:

         [[swap] dip]   swapd\

       However, a lambda could be used for formal variables, when the items

       to name are not statically known. For instance, one could define

       "concat" using lambdas as:

         [x\ y\ [y x]]  concat\

       One could define a "squaring" program as

         x\ [x] [x] *

       Anyhow, I won't go into this anymore, since it has already been

       discussed quite a bit between Billy and I. One could scan through

       the archive of this list (and the TUNES list) for subjects containing

       "Lambda".

    - "iepos" (Brent Kerby)