Re: environment arguments and compiler contexts and ...

[sandra%defun@cs.utah.edu (Sandra J Loosemore)]

This message raises some interesting points.

I've also been a bit wary about how CLOS seems to assume things about
environments, although there's already a problem with the language as
described in CLtL because of MACROLET and MACROEXPAND.  To me it seems
like that if we're going to place additional requirements about what
must be stored in environments, we must also tighten up the notion of
what an environment object is.  Is it supposed to be a distinct type?
Are they guaranteed to be printable and compilable?  How do you add
things to an environment or find out what's in it?  I'm not sure that
we have enough practical experience yet to try to standardize the use
of environments as something like locales in T.

The writeup for issue COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS already
notes that portable program-analyzing programs must generally treat
defining macros as special forms.  If these defining macros are
allowed to store the compile-time definitions in somewhere other than
the normal place (that is, in the environment or some data structure
set up by the compiler, rather than where the interpreter would put
the definition), user program analyzers have no way to access this
information.  Also, it's possible that the compiler might be treating
the defining macros as special forms itself and the macro expansions
might not do any special compile-time magic. 

I'd have to disagree about that requiring program analyzers to know
about defining macros being "bogus", however.  I suspect that an
"industrial strength" program analyzer would want to have special
knowledge about *most* built-in Common Lisp macros, rather than just
expanding them blindly.  The reason for this is that many compilers
treat them as special forms, and while the macro expansions are
correct, they are often much less efficient.  (Some of the multiple
value macros come to mind.)

-Sandra
-------