Namespace, Psets, Order, IDs, Joy (was: Intent)
btanksley@hifn.com
btanksley@hifn.com
Tue, 11 Apr 2000 12:15:23 -0700
From: iepos@tunes.org [mailto:iepos@tunes.org]
>> >Anyhow, a similar technique could be used in a Joy-like system,
>> >so that if the system had a function named "divide" and the
>> >programmer
>> >wanted to call it "quotient", it could be renamed with something
>> >like this:
>> > [divide] "quotient" rename
>> There's no reason to do this -- instead, use definition:
>> quotient == divide.
>Yeah. That would require sugar for "==", but that's no problem.
Not in Joy. In Joy == is fundamental, not sugar. In Forth, and I assume in
your language, it would probably be what you call syntactic sugar.
>I'm not sure why I called the word "rename" up there; it would
>make more sense to be called "def", as it does not destroy
>the original name.
Right; it actually creates a new name which masks the original name.
>> >Or if he had still liked the name "divide" but just wanted
>> >the change the order:
>> > [swap divide] "divide" rename
>> divide == swap divide.
>Yes... That'd be fine too...
Of course, I am assuming a primitive such as 'recurse' to handle recurrance,
since using the current function's name inside its definition doesn't cause
it to call itself. An alternate choice would be to have a primitive handle
calling a hidden word with the same name as the current definition (perhaps
'original'), and have recursion be handled in the usual way.
I suspect that recursion will happen more often than redefining a word.
Just a suspicion.
>There seems to me to be a pretty simple way to get the best of both
>worlds... Let the user decide whether he wants to hang on to the
>textual source code or just the program. In the type of system I'm
>thinking of, if a user was going to write a program, it would probably
>be done with a text editor, like in other systems; then, one would
>use a compiler to convert the text into a program. But then, the
>text could be safely discarded, because all the important information
>in it could be reconstructed from the program.
That may work. I suspect that it's inefficient, though; source code is
_supposed_ to contain more information than binary code; the main reason for
this is that the binary code is supposed to be smaller. (Another reason for
binary code is to allow the compiler to evolve seperately from the user's
machine.)
>But, maybe that would be making the tools too smart, as you say...
No, that's not what I meant -- I think your idea is great. It would only be
making the tools too smart to allow them full reign over the source code AND
allow them to store someone's idea of kewl code formatting.
-Billy