Re: Questions about the compiler et al

[Mark H Weaver]

Hi Andy, thanks for the quick response!

Andy Wingo <address@hidden> writes:
>> * 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?

My more complex `the-environment' patch fully supports captured local
syntax definitions in the evaluator, and would also do so for the
compiler if not for this limitation.  Code generated by
(the-environment) needs to embed references to the captured local syntax
transformers.  I can imagine some hacks to work around this limitation,
but they're not nice.

My more complex patch adds support for attaching an objtable and
free-vars to the compiler environment for use by `objcode->value', and I
successfully used this to attach the free-vars to the compiled closure.

I also did some work on providing a compiler option for
`compile-assembly' to attach the objtable to the target-environment
instead of serializing it as code, but didn't finish that job.  I still
think it might be useful.  Any suggestions (or objections)?

Furthermore, I'd suggest that _not_ serializing the objtable should be
the default behavior, and that `compile-file' should instead add a
compiler option to force objtable serialization.  The rationale is that
I expect most uses of `compile' from within user code to compile to
`value' anyway, and forcing serialization needlessly adds overhead, and
more importantly, limitations on what might be found within (quote _)
forms of generated code.  What do you 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.

I agree that a single extensible representation (like alists) for all
languages is probably best, but I think it's important to make this
representation distinct from modules ASAP, before the assumption that
they're modules becomes too deeply entrenched.

Although it's easy enough for compilers to accept a new representation
while still accepting modules, I'm more concerned about their return
values.  What happens if a bunch of external code is written that
assumes compilers will always return modules as environments?

There's a danger that we might become unable to use environments for
anything else without breaking compatibility.

>> * Do modules created by (make-fresh-user-module) get garbage collected?
>
> In theory, yes.

Is this practical?  Do these fresh modules have names?  If so, can't
references exist to them purely in source code using @@?  The only
reference to them might be from the template of a syntax transformer.

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

I cannot find its implementation anywhere in stable-2.0, but it is still
documented.  I guess it should be removed from the doc, or the doc
should at least mention that it has already been removed.  Or no?

    Thanks,
      Mark