language environments

language environments

[BT Templeton]

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?

-- 
Inteligenta persono lernas la lingvon Esperanton rapide kaj facile.
Esperanto estas moderna, kultura lingvo por la mondo. Simpla, fleksebla,
belsona, Esperanto estas la praktika solvo de la problemo de universala
interkompreno. Lernu la interlingvon Esperanton! http://lernu.net/

Re: language environments

[Andy Wingo]

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?

Andy
-- 
http://wingolog.org/

Re: language environments

[BT Templeton]

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 or OPTIMIZE settings for a hypothetical CL
compiler. They aren't associated with any particular module, and it'd be
preferable for changes to these parameters to be isolated to the
compilation environments. Compiling a `(DECLAIM (OPTIMIZE ...))' form in
a CL program shouldn't change the SAFETY setting at the user's REPL!

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.

Existing programs wouldn't need significant changes -- possibly none at
all, though it might be cleaner to modify the interface of compilation
procedures, perhaps to take `#:module' instead of `#:env'. Some
programs, like the REPL, would need to track the continuation
environment returned by compilers.

WDYT about this proposal? Am I misunderstanding the purpose of language
environments?

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'. ISTM that "joiners" should only
really be required for compilers that perform global transformations.

amike,
BT
-- 
Inteligenta persono lernas la lingvon Esperanton rapide kaj facile.
Esperanto estas moderna, kultura lingvo por la mondo. Simpla, fleksebla,
belsona, Esperanto estas la praktika solvo de la problemo de universala
interkompreno. Lernu la interlingvon Esperanton!

Re: language environments

[Andy Wingo]

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/