[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: language environments
Re: language environments
Tue, 06 Dec 2011 11:20:39 +0100
Gnus/5.13 (Gnus v5.13) Emacs/23.3 (gnu/linux)
BT! Clearly I am a terrible person. Or perhaps I am very close to the
event horizon of a black hole. In any case, sorry for the late reply.
On Tue 12 Jul 2011 04:53, BT Templeton <address@hidden> writes:
> Andy Wingo <address@hidden> writes:
>> On Sat 09 Jul 2011 22:30, BT Templeton <address@hidden> writes:
>>> How are language environments (i.e., the values passed as `#:env'
>>> arguments to the various compilation functions) supposed to be used?
>>> Currently all languages use it as the value of the current module, but
>>> would it be appropriate to use the environment value to keep track of
>>> other compilation-unit-specific settings like the default binding mode
>>> for Elisp or global declarations for CL?
>> For toplevel languages and tree-il they need to be modules I think.
>> Otherwise the REPL won't work. Lower-level languages might do different
>> things, but it's best to think of them as modules. Can these other
>> parameters be attached to modules somehow?
> Some parameters are local to the compilation unit, like the value of
> `lexical-binding' for Elisp
I guess I'd rather use dynamic bindings for this.
> or OPTIMIZE settings for a hypothetical CL
Aren't these lexical? Perhaps my CL ignorance is showing here. Or if
they aren't, could they go in #:options ?
It would be irritating if indeed as you say:
> Compiling a `(DECLAIM (OPTIMIZE ...))' form in a CL program shouldn't
> change the SAFETY setting at the user's REPL!
A similar case is Scheme's current-reader:
;; Ideally we'd duplicate the whole module hierarchy so that
;; `fluid-set!', etc. don't have any effect in the current
(let ((m (make-fresh-user-module)))
;; Provide a separate `current-reader' fluid so that
;; compile-time changes to `current-reader' are
;; limited to the current compilation unit.
(module-define! m 'current-reader (make-fluid))
This is a bit crazy, as it would be better to delimit a new dynamic
binding context rather than allocating a new fluid. We definitely need
> Ideally one would be able to use arbitrary objects for the language
> environment in order to track the values of these sorts of parameters
> (in addition to the current module). I think this would be possible if
> the compilation interface were changed as follows. Remove
> `make-default-environment' and replace it with `make-environment'. A
> language's `make-environment' procedure takes one argument, `inherit?'.
> If true, it should return an environment object capturing the relevant
> parts of the dynamic state (current module, global bindings relevant to
> compilation, etc.); otherwise, it returns a default environment.
> Compilers would have to know about the type of environment object
> required by their target language's compiler; no other code would need
> to know about the environment representation used by any particular
The compiler still needs to know how to get a module from the
environment. Also, in stable-2.0 we need to be careful about
> Some programs, like the REPL, would need to track the continuation
> environment returned by compilers.
Here I'm a bit skeptical. If it is important enough to track in the
REPL, surely it is important enough to track in a module?
It seems to me that you would not have this problem if elisp had
modules. Of course, Elisp doesn't, so we need a solution. What about
dynamic binding? You'd have to define a wrapper around `compile' that
establishes a new dynamic binding context for all of the bindings you
are interested in. Somewhat nasty, but hey.
> One alternative appears to be to add the (undocumented) `joiner' field
> to a language definition so that `compile-file' effectively wraps the
> entire file in an implicit `begin'.
This would be another option, yes.
|[Prev in Thread]
||[Next in Thread]|
- Re: language environments,
Andy Wingo <=