New Issue: SYNTACTIC-ENVIRONMENT-ACCESS

[Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>]

    Date: Fri, 7 Oct 88 17:59:47 pdt
    From: Eric Benson <eb@lucid.com>

    I am about to prepare a revised version of the proposal.  Here are
    some specific replies before I start.  Sorry about the length, but it
    seemed better to reply to all of these together.
    ...

A couple other comments which will hopefully be of use to you in your
new proposal; I asked the others in the Cloe group what they thought of
your proposal -- mostly from a technical impact point of view -- and
this is the kind of thing I got back...

In Cloe Runtime (meaning, our compiler for the 386), the information
you mention is all accessible, but very little of it is stored in the
environment object. Only information about macrolet, symbol-macrolet,
and symbol-macroflet is in the environment object itself. Other information
is obtained dynamically.

The belief is that it would be a fair amount of work for us to put the
information in the environment object and the gain was not made obvious
by the proposal. Can you give an example of a screw case that would come
 from saying the information is dynamically available in the macro only
(ie, you couldn't embed funargs that were closed over the current state
in s-expression and then ask that it be macroexpanded and have the
macroexpander funcall the funarg it found embedded in the structure in
some other environment context ... I can't imagine this ever happening,
and it's one of the only screw cases I could devise).

Basically, they seemed to feel that both of the functionalities you were
considering offering and the manner of presentation (ie, environment
extraction) were somewhat unmotivated. This is not to say that they
thought you had not motivation -- only that you didn't present it in a
way that made them able to figure out how you chose the set of things
you did, what benefits would come, etc. Hopefully the next write-up will
address this issue in greater detail.