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)

three more proposals about Joy

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