Am Fr., 7. Jan. 2022 um 19:35 Uhr schrieb Shiro Kawai <xxxxxx@gmail.com>:
>
> I haven't been able to participate in the discussion for a while, and can't say I fully understand the issue here, but anyway--
>
> - I agree that the case mixes expansion-time and runtime environments.
> - I'm not sure I understood the 'eva' argument--in what case does it make difference to import (possibly AOT compiled) bar in your library and import it within eval?

When eval is used at runtime and imports the library (bar), it needs
the expanded version of the library. To prevent inconsistencies there
must, however, be only one instance of a library expansion for each
program. Now the expanded version of the library contains a runtime
object - which cannot usually be saved in the executable - so the
library must not be expanded before runtime. This, however, means that
a program that imports (bar) statically can also not be expanded (and
thus compiled) before runtime.

--

Marc

> - A compromise may be to say that the SRFI spec excludes the use case other than (3)---i.e. once you carry over the environment across phases, the behavior is implementation dependent.  It would be pretty hairy for implementations to detect such cases for arbitrary code, so it's up to users.  Implementations may mark the phase internally and raise an error at runtime if an environment from the wrong phase is used.
>
>
>
> On Fri, Jan 7, 2022 at 6:47 AM Arthur A. Gleckler <xxxxxx@speechcode.com> wrote:
>>
>> Does anyone have any feedback for Marc on the issue of syntactic closures and ahead-of-time expansion of libraries?  This is one of the last issues that he wants to address before finalization.
>>
>> Thanks.
>>
>> On Fri, Nov 19, 2021 at 1:07 AM Marc Nieper-Wißkirchen <xxxxxx@nieper-wisskirchen.de> wrote:
>>>
>>> SRFI 211 is mostly done except for the exact specifications of the syntactic closures macro facility (SC).  During the last few days, I have spent some time thinking about how to write down the semantics as concisely as possible.
>>>
>>> I occurred to me that SC is not compatible with AOT expansion of libraries.  For example, consider the following sample library:
>>>
>>> (define-library (bar)
>>>   (export bar)
>>>   (import ---)
>>>   (begin
>>>     (define-syntax foo
>>>       (sc-macro-transformer
>>>         (lambda (form env)
>>>           `(define-syntax ,(close-syntax 'bar env)
>>>              (syntax-rules ()
>>>                ((_) ,(capture-syntactic-transformer (lambda (env) ---))))))))
>>>     (foo)))
>>>
>>> The expansion of this library will include a definition of a syntax-rules macro `bar`.  The expansion of this macro includes the form returned by `capture-syntactic-transformer`.  This form, however, is an object existing only at expansion time of the library because it encloses a procedure `(lambda (env) ---)`, which only exists during expansion.
>>>
>>> Thus, the Scheme system cannot expand the library `(bar)` ahead of time.  In other words, SC doesn't allow for phase separation.  Even worse, `eval` could import and use this library,  Thus, strictly speaking, not even AOT compilation is possible.  (A way out here would be to work with separate expansions of `(bar)` during compilation and runtime, but the paper [1] shows that this would lead to inconsistencies).
>>>
>>> Does anyone have an opinion about that? Three resolutions are possible:
>>>
>>> (1) There's a flaw in my argument above.
>>> (2) We accept the fact that SC is not compatible with phasing and AOT expansion/compilation.
>>> (3) We restrict the uses of the form returned by `capture-syntactic-transformer`.
>>>
>>> As for (3), what would you suggest?
>>>
>>> Marc
>>>
>>> --
>>>
>>> [1] Dybvig/Ghuloum: Implicit Phasing for R6RS Libraries
>>>
>>>