[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Gcl-devel] Re: SYMBOL-MACROLET problem
From: |
Paul F. Dietz |
Subject: |
[Gcl-devel] Re: SYMBOL-MACROLET problem |
Date: |
Tue, 29 Oct 2002 21:12:25 -0600 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020826 |
Camm Maguire wrote:
GCL currently does macroexpansion in C. Can you
elaborate a little on your suggestion below to implement this "at the
same place" as ordinary macroexpansion? Is there some sort of subtle
interplay between symbol-macrolet and macroexpand? From your note,
and what I read in the spec, my current understanding is that what
this should do is simply go through the code as a list, make all
substitutions not shadowed by an internal let, and then pass the
result out for normal evaluation. I must confess that my grasp on
lisp evaluation is still rather primitive, however.
Symbol macroexpansion should be done at the same time as ordinary
macroexpansion.
There should be a routine in gcl's guts that implements macroexpansion
at a form. It dispatches off the car of a list, doing an expansion
if that car is a symbol that has a macro binding in the current environment
(which means basically it was defined with defmacro or an enclosing
macrolet).
What we need to do is augment this function so that if the form is
a symbol, it checks if that symbol has a symbol-macro binding in the
current environment. If so, it substitutes the expansion form associated
with that symbol. (Actually, that's not quite right; there can be
interaction with the macroexpand hook; see section 3.1.2.1.1 of the spec.)
The data structure for environments needs to be augmented
so that it has a symbol macro information.
What we *can't* do is walk the term separately (either before or
after macro expansion) doing symbol macro substitution.
Paul
- [Gcl-devel] Re: SYMBOL-MACROLET problem,
Paul F. Dietz <=