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

Re: Macroscope



CC: (BUG LISPM) at MIT-AI, (BUG LISP) at MIT-AI, KMP at MIT-MC
    GLS@MIT-MC 09/18/79 10:24:48 Re: Macroscope
        RWK@MIT-ML 09/18/79 03:57:37 Re: Macroscope
        Often macros would like to know if they're called for value or effect.
        ...

    ...
    Actually, another thing a macro sometimes wants to know is the set
    of variables lexically bound around its invocation...

There are all sorts of things a macro might want to know about
about the context it is expanding in. Often I have wanted to
communicate something to all the macros that are expected to expand
in a particular scope. The LispMachine's COMPILER-LET is a special form
that can be used to perform such feats of macrology. In the interpreter
COMPILER-LET acts just like LET, but in the compiler the variables
are bound at compile time for the benefit of anyone who would care to
look at them during the time that the body of the COMPILER-LET is being
processed.
	If we are going to start providing reasonable expand-time environments
to macros, then I would like to see COMPILER-LET introduced to the NIL and
MacLisp worlds at the same time that any special variables that the compiler
whould be obligated to bind are introduced to all three.
	One issue is going to be: to what are these special variables to
be bound in the interpreter?  Perhaps you should have to do a (status complr)
before you can feel safe looking?  Or perhaps reasonable constant values
can be found, for example, it should always be safe to assume that
you are expanding for value.
	Anybody have any reasonable suggestions for names to give to
these specials? Or any other things the compiler could provide to
the curious macro?