Hi Andy, thanks for the quick response!
Andy Wingo <wi...@pobox.com> 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
