Re: language environments

[Andy Wingo <wingo@pobox.com>]

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 <bpt@hcoop.net> writes:

> Andy Wingo <wingo@pobox.com> writes:
>
>> On Sat 09 Jul 2011 22:30, BT Templeton <bpt@hcoop.net> 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/