> >
> >The second kind of definition can easily be implemented in the interpreter. If the interpreter keeps a dictionary and looks up each name encountered to find the corresponding op -- instead of just using a case statement or if-elsif series to match names to ops -- then "macro definition" can be done in the language itself with one primitive:
> >
> >[dup mul] "square" define
> >
> >
> >define takes a quotation and a string and adds an entry to the interpreter dictionary (key, value) is (string, contents of quotation). After the above code is executed,
> >
> >[2 3 4] [square] map
> >
> >will be parsed as
> >
> >[2 3 4] [dup mul] map
> >
> >Now for the confession: this is the only kind of definition my machine has. I hadn't realized before this morning that there were two kinds. The machine is written in Oberon.
> >
> >sr
>
> 1. There are two possible styles:
> [dup mul] "square" define
> "square" [dup mul] define
> I have a suspicion (just a suspicion) that the second style would be
> more useful. Of course one could always do a swap first to get the
> other style.
>
> 2. If your definitions always do the textual replacement as you
> indicated, then you will not be able to have simple recursive
> definitions, and even less mutually recursive definitions. For
> recursion you do need the notion of a function calling itself,
> so the functions need to be _called_ at run time. In that case
> [square] size == 1
> of course.
>
> 3. In my prototype I use a particular method of garbage collection
> and a small device which saves some collection time. It would take
> long to explain what the device is, but I regret it already. The
> upshot is that the two dynamic styles of definitions would not
> fit easily into my prototype implementation. This is just a warning
> in case anybody tries to add dynamic definitions to my prototype
> implementation.
>
I'm not sure that my define is dynamic. Here's why: it is not possible to define a word and then use it immediately. The parser will not recognize the word until the define has been executed.
[dup mul] "square" define 3 square
The parser will choke on this.
[dup mul] "square" define
The program is parsed. The program is executed. Now "square" is in the dictionary.
3 square
Parses and runs.
This is not a flaw in my opinion. The language can be changed with "define" but is immutable within a single program. As for recursion, I thought that was handled with combinators. Is there a reason to do it with macros? Now to GC.
Garbage collection for Joy is very easy, in theory, as anyone who as looked at Henry Baker's papers on linear languages already knows. It is not necessary to trace the tree of live objects or to keep reference counts, because every object in Joy has exactly one reference to it and the tree is only a list. There is no mystery about when objects become garbage, so collection should be trivial.
This being said it must be admitted that my machine doesn't collect at all. It just lets Oberon's GC act as a backstop.
sr