Re: Issue SYNTACTIC-ENVIRONMENT-ACCESS

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

Well, this writeup looks better than the last one, but I still don't 
think it's quite ready to be voted on yet.


I have some editorial comments on the last paragraph of the problem
description:

> Implementing the FIND-CLASS and ENSURE-GENERIC-FUNCTION functions of CLOS
> requires the ability to distinguish between environments used for compiling to
> a file from those used for processing in-core, such as by EVAL or COMPILE.
> Resolution of the LOAD-TIME-EVAL issue may also require this information.
> This problem has been addressed by the recent cleanup issue
> COMPILE-FILE-ENVIRONMENT.  Also, it has proven impossible to write a portable
> code walker in Common Lisp, due to insufficient access to the information
> contained in environments and the inability to augment environments with local
> function definitions.

I'm not sure that saying "CLOS requires" this is entirely accurate.
My impression is that it would be possible to implement the
functionality described in Chapters 1 & 2 without this.  It mentions
that an environment object might be used to distinguish between
compile-time and run-time environments, but doesn't specify any
different behavior for the two cases.  Perhaps more accurate wording
would be to say "the CLOS meta-object protocol assumes...".

I don't see the connection to LOAD-TIME-EVAL.  There's certainly
nothing in the current writeup that depends on users being able to look
at the contents of environment objects.

My understanding was that this issue subsumed issue COMPILE-FILE-ENVIRONMENT.

I'd agree that writing a truly portable code-walker is impossible, but
not for the reason you cite.  (The real problem is macros that expand
into nonportable syntax.)  How about saying that not having environment
accessors makes it "difficult".


>  AUGMENT-ENVIRONMENT env &KEY variable
>                               special
> 			      symbol-macro
>                               function
>                               macro
>                               type
>                               ftype				[Function]
> 

I have a couple of suggestions here.  

How about combining the SPECIAL, TYPE, and FTYPE arguments into a
DECLARE argument that takes a list of "decl-spec"s?  Breaking them up
requires you to do your own parsing of declarations.  This would also
solve the problem of what to do if a LEXICAL declaration is added to
the language.

Also, I'd suggest that the values for the :SYMBOL-MACRO and :MACRO
arguments be supplied in the form of the list that is the CADR of the
SYMBOL-MACROLET or MACROLET form.  Maybe this is what you intended,
but it's not clear.  Anyway, the rationale for this is that if you
want the :MACRO argument to be real "macro functions", people who
write code walkers would have to write their own macro argument
destructuring code, which is really a pain.  Have the implementation
do it.


> ENVIRONMENT-PROPERTY env name property &optional default

I'm still not convinced that we really need this feature.  It seems
more like a mechanism that implementations might use internally.  I'd
suggest having two proposals: one that includes everything but this,
and one that adds this feature.  I don't think "this is needed to
implement CLOS" is a good enough excuse for adding something to the
language.  There are lots of things necessary to implement other parts
of the language that we haven't made visible to the user.


> WITH-REMOTE-ENVIRONMENT var &body body				[Macro]
> 
> RECORD-ENVIRONMENT-CLEANUP env function			[Function]

Yuck.  Why not use a syntax like unwind-protect?

WITH-REMOTE-ENVIRONMENT var protected-form {cleanup-form}*


>  MAKE-NULL-ENVIRONMENT &optional env				[Function]

I don't think this function is necessary.  When your code walker
encounters a LOAD-TIME-VALUE form, you presumably still have a handle
on the null, remote environment that originally got created with
WITH-REMOTE-ENVIRONMENT.  All this function does is retrieve it,
right?

-Sandra
-------