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)
|
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