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

Re: issue SYNTACTIC-ENVIRONMENT-ACCESS, version 4



Either alternative SMALL or LARGE is reasonable, but I don't think that
MEDIUM is viable because ENVIRONMENT-REMOTE-P and
WITH-REMOTE-ENVIRONMENT aren't very useful if you don't have
ENVIRONMENT-PROPERTY.  ENVIRONMENT-REMOTE-P might be useful in
conjunction with FIND-CLASS, but the use of environments by FIND-CLASS
seems to be in question now.

>   Using SETF of ENVIRONMENT-PROPERTY affects all environments which
>   refer to the same environment model.  In particular, if ENV is a
>   local environment then all local environments are affected, ...

Need to make clear that this affects the global environment, not just
all local environments.

>		... while if
>   ENV is a remote environment, then all environments refering to the
>   same remote environment model as the argument are affected.

"same model" is not a defined term; would be more precise to say all
environments which inherit from the same remote environment.

>  An possible alternative syntax for WITH-REMOTE-ENVIRONMENT might be
>    WITH-REMOTE-ENVIRONMENT (var &key) &body body
>  Can anyone suggest candidates for keyword options?  We could do this
>  even if we can't think of any immediately, leaving room for
>  implementation-specific extensions.  One candidate option that some
>  implementations might want would be to specify a target machine for
>  the compilation.

Yes, I think that would be a good idea.  For cross-compilation, I would
want the COMPILE-FILE remote environment to inherit from a remote
environment representing the target machine.  How about a :PARENT option
for specifying a parent environment?