gcl-devel
[Top][All Lists]
Advanced

[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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]