Syntactic closures and phasing Marc Nieper-Wißkirchen (19 Nov 2021 09:06 UTC)
Re: Syntactic closures and phasing Arthur A. Gleckler (07 Jan 2022 16:47 UTC)
Re: Syntactic closures and phasing Shiro Kawai (07 Jan 2022 18:35 UTC)
Re: Syntactic closures and phasing Shiro Kawai (07 Jan 2022 19:48 UTC)
Re: Syntactic closures and phasing Marc Nieper-Wißkirchen (08 Jan 2022 08:48 UTC)
Re: Syntactic closures and phasing Shiro Kawai (08 Jan 2022 09:13 UTC)
Re: Syntactic closures and phasing Marc Nieper-Wißkirchen (08 Jan 2022 10:13 UTC)
Re: Syntactic closures and phasing Marc Nieper-Wißkirchen (11 Mar 2022 17:41 UTC)
Re: Syntactic closures and phasing John Cowan (11 Mar 2022 19:41 UTC)
Re: Syntactic closures and phasing Marc Nieper-Wißkirchen (12 Mar 2022 09:08 UTC)
Re: Syntactic closures and phasing John Cowan (08 Jan 2022 01:24 UTC)
Re: Syntactic closures and phasing Marc Nieper-Wißkirchen (08 Jan 2022 08:54 UTC)

Re: Syntactic closures and phasing Marc Nieper-Wißkirchen 12 Mar 2022 09:07 UTC

Am Fr., 11. März 2022 um 20:41 Uhr schrieb John Cowan <xxxxxx@ccil.org>:
>
>
>
> On Fri, Mar 11, 2022 at 12:41 PM Marc Nieper-Wißkirchen <xxxxxx@nieper-wisskirchen.de> wrote:
>
>>
>> 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.

Let me define my terminology first: When I speak of AOT compilation, I
don't mean a model of compilation where a whole Scheme process is
saved in form of a process image. That model is from the theoretical
point of view equivalent to one long-running process so calling it
"AOT" would be meaningless. As the issue we are talking about here
only touches AOT compilers, Scheme systems that are image-based are
not affected (and can support the syntactic-closures model).

> I see two strategies here:
>
> 1) The GNAT strategy, where all dependencies along with the date at which the source was last changed are stored in the compiled object file (in practice, in a text file that is also a product of compilation).  In that way, it can be known when recompiling is required.

I don't understand how this relates to the problem discussed. In the
example, the source file doesn't change. The point is that expanding a
source file is not a mathematical function (when we have procedural
macros) so, for consistency, in a running program there must only be
one expansion per source file (library).

> 2) A CL-style strategy, in which code to construct the compiled object (the analogue of quasiquote) is stored in the executable.

How can runtime objects (like a closure in the example above) be
stored in an executable (ignoring image-based Schemes as described
above)?

Thanks,

Marc