[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

macros in Interlisp

The problem seems to be a matter of terminology rather than the effect that the
user sees or the actual implementation of macro translation.

There is a misunderstanding that "DWIM" in Interlisp means "error" correction.
The term "DWIM" has been overloaded to include many different mechanisms,
some of which are an integral part of "normal" execution, including macro
translation, the record package, iteratives, etc. This doesn't mean that the
implementation isn't modular, only that the documentation calls all of them by
the same name rather than making up new names for every little feature. 

The mechanism by which macros get translated, functions get auto-loaded, etc. is
a "fault handler" rather than an "error handler" (e.g., the interface to the
interpreter is via FAULTEVAL and FAULTAPPLY).  An analogy can be drawn
to the implementation of virtual memory: the hardware may do virtual to real
translation for some pages, but if the page is not in real memory, it goes outside
of the emulator/microcode to a macrocode pagefault handler. One can think of
macros, auto-load, etc. as extensions to the "virtual" definition space.
Once a macro gets translated, the fault handler is no longer called.

It has been useful to have the fault-handler user accessible, for a variety of
syntax extensions which have not always been prefix-driven.  

In one light, the problem might be that there is not in Interlisp a "clear division
between the interpreter and the error signal/correction facility [as] in Maclisp."
I am uncertain where this division should be: is auto-load part of the interpreter?
I can imagine situations where you might want to include some sort of data-base
lookup to find out where to do the auto-load from -- is that database lookup part
of the interpreter too?

Finally, I don't think that making the interface from the interpreter to the fault
handler compatible was a major problem in producing compatible Interlisps for
any of the current implementations, compared to the magnitude of the total task.