Am Sa., 26. Sept. 2020 um 00:07 Uhr schrieb John Cowan <xxxxxx@ccil.org>:

>> I am not sure whether the term "native implementation" is
>> well-defined.
>
>
> By that I mean that it is not built on top of any other implementation.

We mustn't mix up implementations with interfaces. For example,
syntax-case is not an implementation, but an interface, which can very
well be provided by fundamentally different types of implementations
(like, say, Chez/Racket/Larceny show).

For example, Unsyntax uses the marks and substitutions algorithm of
Dybvig together with a notion of a syntactic closure to implement
syntax-case/er-macro-transformer/ir-macro-transformer.

In the end, a user doesn't care what the underlying algorithm is as
long as it works. All algorithms are well-understood and sufficiently
simple to implement so that they can be switched out in case an
implementation hits a wall.

> Indeed.  And the questions "What belongs in this SRFI?" and "What goes into R7RS-large?" are very much unlike "Is 1 prime?"  They are much more like "What are the boundaries of country X?", which is a matter of fact until it is not.

Agreed. Questions I had in mind are, say, whether pattern variables
are matched with those in a template in syntax-rules through
bound-identifier=? or free-identifier=?. Such a question came up in
the discussion of SRFI 148 as the various systems had implemented them
differently. But there is only one "right answer"
(bound-identifier=?), which became clear in the discussion.

Similarly, if we just specified the current behavior of ER macro
implementations in the case of raw symbols in the output, we would get
a specification, which is factually bad.

>> That said, I can fill in specifications but these will probably (have
>> to) make choices, which I am currently evading (especially in the case
>> of ER macros).
>
>
> You will have to, I think.

I have heard you and Alex. :)

>> I would rather want to find a substitute for the (srfi 211 r4rs)
>> library name, which I just chose for the lack of a better name. Maybe,
>> (srfi 211 low-level) is already a better name.
>
>
> That makes sense to me.

So... (srfi 211 low-level).

>> PPS We have almost only talked about the implementations but the users
>> matter at least as much. Given the scope of R7RS (large), high-quality
>> implementations will matter more than toy implementations.
>
>
> That's true.  But I am constrained by my position as chair of R7RS-large from having public views on which implementations are high-quality and which are toys.

And the definition of "high-quality" is not of the same type as the
definition of a prime number.

My point is that one reason for splitting the language was that to
have a language that can be easily supported by almost all existing
implementations and to have a language in the scope of R6RS++, for
which we don't expect that every hobby implementation has the manpower
to provide a complete implementation.

That said, when it comes to syntax, I'll try to keep the Unsyntax
frontend as much up-to-date as possible so that it can be used as a
drop-in replacement much like psyntax was used for R6RS. This way, I
hope, we can solve some questions more from a user perspective than
from a perspective of what is already available in the implementations
of those active on these mailing lists.

>
>>   (I doubt anyone wants to write applied macros like these
>>
>> with er-macro-transformer.)
>
>
>  I certainly would not.  But then I don't want to write low-level macros at all.  If I were writing a multipass compiler like that, I'd do it at the runtime level.

In this context, "procedural macro" is probably the better term.

What do you mean by "at the runtime level"? That you would write a
code generator that produces the Scheme code, which is then finally
compiled? But this way, you would have to reinvent everything because
your code generator would effectively be an expander.

The nice thing about Scheme procedure macros is that one's expand-time
level is the other one's run-time level. As soon as you pass to the
right-hand side of define-syntax, you have done the shift.

It is pretty nice a feature of the syntax-case system that you can
actually test your macro transformer at the absolute runtime level,
meaning at the REPL because a transformer is nothing but a procedure,
which you can experiment with as with any other procedure. No other
system is as simple as this in this regard (apart from the R4RS
system).