Am Do., 17. Feb. 2022 um 13:13 Uhr schrieb Martin Rodgers <
mcro...@gmail.com>:
>
> On 17/02/2022, Marc Nieper-Wißkirchen <
marc....@gmail.com> wrote:
>
> > At least for R7RS-small, all three libraries are optional features.
> >
> > The criteria by which you selected these three libraries are not clear
> > to me, though. The libraries (scheme load) and (scheme repl) are
> > directly tied to the dynamic evaluation issues we have been discussing
> > here, so I understand why these. The library (scheme eval), however,
> > is unproblematic. The only problematic case is mutable environments,
> > but they are not exported by (scheme eval).
>
> How else is the compiler going to evaluate the expressiong using
> syntax-case? It implies some kind of development environment beyond
> the compiler itself. I.e. somewhere for the compiled code to *run*.
> I.e. dynamic generation of code at the compiler's runtime.
Dynamic evaluation of code is orthogonal to the question of dynamic or
static environments (e.g. the question of REPL or static library body
semantics).
The environment, in which syntax-case transformers are evaluated,
won't be mutable; only expressions but not definitions are evaluated
when the right-hand sides of syntax definitions are processed.
> This has some small relevance to this discussion, as it includes macro
> defintions. However, the presence of the REPL "solves" the syntax-case
> issue in one important detail - it provides a way to dynamically
> define and run new code.
Apart from that the REPL and the syntax-case expander can share a lot
of code of the respectively underlying eval mechanisms, I don't see a
close connection.
> I mentioned the distinction between compiled and interpreted code in
> my earlier post. Cambridge Lisp / Standard Lisp conflated the
> compile-time and runtime environments, while Common Lisp directed
> addressed the distinction with eval-when. This issue is independant of
> expand phases, which are specific to hygienic macro languages, like we
> have in Scheme. Taylan Kammer's recent post describes the renaming of
> a variable, which is a correct of environment splicing.
For Scheme, at least for R6RS Scheme (I can't add R7RS-large yet,
because these things haven't been fixed there yet), I think it is
better to talk about "visit-time" and "invoke-time" because the
run-time of one library can happen during the expand-time of another
library. A way to remove the need of something like eval-when are meta
definitions as described here ([1]). These build directly on the
phasing model of R6RS.
> > As you write, compile-time evaluation is needed anyway for syntax-case
> > (or any other procedural macro system). Fortunately, as far as
> > syntax-case is concerned and when some kind of phasing is adopted from
> > R6RS everything is well-defined. There is no question about the
> > language used by syntax-case (transformers). But, please, open another
> > thread to discuss this if you think my claim is not correct or
> > questionable so that we can discuss it and see to iron out what's
> > problematic.
>
> I intend to. The R6 library language and the module language in Oscar
> Waddell's Phd thesis address an issue that seems to me as-yet
> unspecified in R7's library language.
I agree; voting for a procedural record system in R7RS-large was just
a first step. Now we have to integrate it with the rest of the
language, especially with the module system. Fortunately, R7RS's
module system is basically the same as R6RS's module system so we
could decide just to copy over the relevant parts from chapter 7 of
the R6RS verbatim. However, I think it makes a lot of sense to discuss
explicit vs. implicit phasing first. The situation with R6RS is not
optimal. Neither the benefits of implicit vs. explicit phasing are
achieved because R6RS has to be compatible with both.
[1]
https://www.unsyntax.org/unsyntax/features/syntax/meta/phasing/2020/10/22/meta-definitions.html