meta comments Alex Shinn (24 Sep 2020 21:58 UTC)
Re: meta comments Marc Nieper-Wißkirchen (25 Sep 2020 05:35 UTC)
Re: meta comments Alex Shinn (25 Sep 2020 23:09 UTC)
Re: meta comments Marc Nieper-Wißkirchen (26 Sep 2020 08:15 UTC)
Re: meta comments Marc Nieper-Wißkirchen (26 Sep 2020 17:09 UTC)
Re: meta comments Arthur A. Gleckler (20 Jan 2021 01:45 UTC)
Re: meta comments Marc Nieper-Wißkirchen (20 Jan 2021 06:49 UTC)

Re: meta comments Marc Nieper-Wißkirchen 26 Sep 2020 08:14 UTC

Am Sa., 26. Sept. 2020 um 01:09 Uhr schrieb Alex Shinn <xxxxxx@gmail.com>:

> Either "Macro Systems" or "Macro System Libraries" would be better.
> "Namespaces" has a specific technical meaning actually provided by some Schemes.

Thank you very much. "Macro System Libraries" is a great name; I will use it.

> That in itself is a problem.  Pointing to the various manuals at
> the time the SRFI was written is not a sufficient specification.
> Those documents are ephemeral, and may change or no
> longer have the relevant information in the future.

This is not universally the case. The R4RS is stable, Clinger's
document is stable, the R6RS is stable as well.

But you are right that it may not be the case with Chicken's
documentation, for example.

> No it's not.  There is no specification of SC, and the manual
> leaves much to be desired (I implemented an SC variant, but
> don't really understand it myself). The purpose of a SRFI

I have noted that Chibi does not implement MIT/GNU's SC completely;
for example, capture-syntactic-environment
seems to be missing.

I think I understand the documentation of SC and would say it can
serve as a specification. What is less clear, though, is how to make
it work together with other macro systems, say syntax-rules. At least
that is missing in the documentation.

> There is also no specification of ER (or IR) macros, though
> Clinger's paper is clearer and they are simple enough people
> tend to end up with the same thing.  However it doesn't mention
> the `syntax-quote' provided by Chibi without which it's nearly
> impossible to write syntax-defining macros (like syntax-rules).

Clinger mentions `syntax' in his paper. And it is provided in (srfi  211 r4rs).

> `with-ellipsis' looks trivial enough that the Guile manual almost
> constitutes a specification, but that full text belongs in the SRFI.

It is not much work to provide the text with this SRFI.

> But this seems like a pretty random macro utility to single out
> in this SRFI.

No, it's not pretty random in the scope of this SRFI. The R6RS
syntax-case can easily implement the R6RS syntax-rules, but it cannot
implement as easily the custom-ellipsis-identifier-SRFI
46/R7RS-extension. With-ellipsis was a very clever idea of, if I am
not mistaken, Mark H. Weaver how to add the SRFI 46 improvement to
syntax-case. In the context of R7RS, you would have an incomplete
system without.

> Since we already have SRFI 93, I would suggest just starting

SRFI 93 (withdrawn) has been superseded by the R6RS. So we should
rather refer to R6RS than to SRFI 93. That said, I just notice that we
should make an adjustment in this context, namely that the underscore
and the ellipsis are allowed as a literal identifier.

> with a new SRFI for ER macros with an actual specification.

I prefer to put a specification for ER macros into this SRFI because
the various libraries are not totally independent as are their
implementations. For example, it is enough to specify
`bound-identifier=?' in the lowest common denominator, the (srfi 211
r4rs) library.

> Programmers can cond-expand on the two.  SC is rare enough
> that I wouldn't bother in portable code, but if someone is
> really motivated they can create an SC SRFI.

For experimentation and while implementations are catching up,
programmers may want to try as many systems as possible.

In the long run, for real-world programs, programmers won't probably
want a single cond-expand. :)