Re: Questions about the compiler et al

[Andy Wingo]

Hi Mark,

On Thu 05 Jan 2012 01:03, Mark H Weaver <address@hidden> writes:

> * Why do compilers return two copies of the same environment?
>   What is the intended meaning of these two return values?

>From "The Scheme Compiler", in the manual:

       Compiler procedures take three arguments: an expression, an
    environment, and a keyword list of options. They return three values:
    the compiled expression, the corresponding environment for the target
    language, and a "continuation environment". The compiled expression and
    environment will serve as input to the next language's compiler.  The
    "continuation environment" can be used to compile another expression
    from the same source language within the same module.

       For example, you might compile the expression, `(define-module
    (foo))'. This will result in a Tree-IL expression and environment. But
    if you compiled a second expression, you would want to take into
    account the compile-time effect of compiling the previous expression,
    which puts the user in the `(foo)' module. That is purpose of the
    "continuation environment"; you would pass it as the environment when
    compiling the subsequent expression.

> * What is the logic behind the handling of returned environments by
>   compile-fold and read-and-compile?

To preserve compile-time changes of the current module, while compiling
a sequence of forms, while not allowing those side effects to leak out
to the caller of `read-and-compile' (I think?).

> * Should we move to support compiler environments that are not simply
>   modules?

Perhaps.  It used to be the case that things were different: see
f95f82f8e183f2744740bdc950dba9c856e09094.  But it turned out that having
environments that could only be interpreted by specific languages made
it difficult to have a generic language tower, so I changed them all to
have one representation, namely, as modules.

> * Should we support distinct environment types for different languages,
>   or use a simple uniform type for all, e.g. an alist?

Uniform, please!

> * Why does code in analyze.scm check (module? env) in so many places?
>   Is it expected that sometimes env will not actually be a module?
>   Is it important to support this?

Probably something legacy-related.

> * Is there any way to embed references to non-serializable objects in
>   compiled code?

No.  Can you give an example of when you would want this?

> * Do modules created by (make-fresh-user-module) get garbage collected?

In theory, yes.

> * Why is `procedure-environment' still documented as "Very deprecated"?
>   Is it still available at all?

It is removed in master.

Andy
-- 
http://wingolog.org/