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 <[email protected]> writes: > Andy Wingo <[email protected]> writes: > >> On Sat 09 Jul 2011 22:30, BT Templeton <[email protected]> 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 > compiler 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: #:make-default-environment (lambda () ;; Ideally we'd duplicate the whole module hierarchy so that `set!', ;; `fluid-set!', etc. don't have any effect in the current environment. (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)) m)) 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 something better. > 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 > language. 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 compatibility. > 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. Regards, Andy -- http://wingolog.org/
