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


Here's another issue relating to macro environments.  I know that
issue SYNTACTIC-ENVIRONMENT-ACCESS also proposes a solution for the
same problem (among the many other things it includes), but since we
don't seem to be making much progress on this issue I thought we might
make more progress with a simpler proposal dealing with this one very
critical aspect in isolation.  Adoption of this proposal would not rule

Forum:		Compiler
References:	CLtL p. 145-146
Edit History:   V1, 10 Jan 1989, Sandra Loosemore
Status:		**DRAFT**

Problem Description:

There is no way for a user to write a portable code walker which will
correctly expand macros that use the &ENVIRONMENT argument, because
there is no way to construct a non-null environment object in the
format expected by MACROEXPAND.  While the code walker could
potentially use its own environment format and its own macro expansion
function, there is still a problem because user macros are allowed to
call MACROEXPAND themselves in computing their expansions.

The problem is not as critical with other kinds of information which
is typically stored in lexical environments (such as local function
definitions and type declarations), because there are no other "hooks"
by which user programs can access this information about the 
surrounding environment.


Add a new function:

MAKE-MACRO-ENVIRONMENT definitions &optional environment	[Function]

  This function creates a new macro environment object which 
  incorporates the macro definitions specified by the argument
  DEFINITIONS.  The value of this argument should be a list in 
  the same form as the first argument to the MACROLET special form.

  If the ENVIRONMENT argument is provided, it should be a macro
  environment object representing the outer lexical environment
  in which the local macro definitions are made, or a value of NIL
  to indicate a null environment.  The default is NIL.  Note that
  this object is not modified by this function.

  The environment object returned by this function is suitable for
  passing as the environment argument to MACROEXPAND or MACROEXPAND-1.
  Like environment objects received by the &ENVIRONMENT argument to
  a macro, it need not be a complete lexical environment, as long as
  it contains the information about local macro definitions.


  (defun walk-form (form env)
    (cond ...
          ((and (consp form) (eq (car form) 'macrolet))
	   (walk-macrolet form env))

  (defun walk-macrolet (macrolet-form outer-env)
    (let ((inner-env (make-macro-environment (cadr macrolet-form) outer-env)))
      (dolist (body-form (cddr macrolet-form))
        (walk-form body-form inner-env))))


This makes it possible to write a portable code walker.

Passing the definitions of local macros in the same form as they appear
in a MACROLET special form makes MAKE-MACRO-ENVIRONMENT very easy to
use.  For example, it obviates the need for users to write their own
code for destructuring macro argument lists.

Current Practice:

Lucid Common Lisp appears to have a similar internal function called

While most other implementations probably include similar
functionality internally, probably no implementation has a function
which exactly matches that described here.

Cost to implementors:

Probably fairly minor.

Cost to users:

Since this is an extension, no user code should be broken if it is


This proposal fills a gaping hole in the language.


Issue SYNTACTIC-ENVIRONMENT-ACCESS provides a much fancier set of
functions for manipulating environment objects, including information
about lexical variables, functions, declarations, etc..  However, some
people feel that proposal is unnecessarily complicated.  Issue
MACRO-ENVIRONMENT-CREATOR is an attempt to separate out the most
crucial problem in the hope that we will have an easier time agreeing
on a solution.  Adoption of this issue would not prevent the adoption
of the more elaborate functionality proposed in issue