Re: language environments

[BT Templeton]

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 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!