Am Mo., 26. Juli 2021 um 01:37 Uhr schrieb John Cowan <[email protected]>:
> > The one with syntax-case/ER is Kronos. Everything in Kronos has a SRFI > too, but they are all non-portable. (Note that as things get voted in, > non-portable code may become portable.) > > [Kronos] is also nearly completely SRFI’d — we don’t have formal >> specifications for explicit renaming macros (cough, SRFI 211?), > > > I've fixed the link to the MIT Scheme description, which will serve as the > Specifications section. Marc mentioned that to make it interoperate > properly it needs free-identifier?, which will just be eq? on existing > systems. > Bound-identifier=? is what is needed. Free-identifier=? roughly is the COMPARE argument to er-macro-transformer. The MIT Scheme documentation of er-macro-transformer includes the usual mistake of presenting unhygienic macros (like loop/while), which are broken with legacy er-macro-transformer implementations and do not work as intended. There's a new draft of SRFI 211 and I plan on getting it finalized soon. Feedback would be very welcome, of course. NB: Er-macro-transformer has other serious deficiencies that cannot be easily fixed by SRFI 211, like missing encapsulation/lexical scoping when macros are composed of procedures: The RENAME procedure only takes the syntactic environment of the macro definition site into account, not where the symbolic name of the identifier is being renamed. So all bindings of all identifiers that may appear in the macro output have to be visible at the macro definition site, breaking encapsulation. > nor of the Racket/Gerbil syntax-case extensions I proposed (but they can >> be kicked down into a subsequent ballot if necessary), > > > Moved to the new Iris Docket (non-portable, non-SRFI). > > nor of Guile’s with-ellipsis which is necessary to support R7RS's extended >> form of syntax-rules in a syntax-case-based implementation (again, SRFI >> 211). I think it would be helpful to have an answer to these questions >> sooner rather than later. >> > > My only objection is political. Nobody has voted on any R7RS dockets for > many years (mea maxima culpa), and I am afraid what will happen if we throw > them into controversial waters right away. I expect Orange to be > relatively calm by comparison, and if we can get through it alive, we can > move on to Kronos. > Although probably futile, I repeat my objection against the voting process, which I don't think produces the best language possible. It has the tendency of producing somewhat arbitrary results due to the fact that not everyone voting is fully informed about all pitfalls in all topics to be voted on, because lobbying may guide an individual decision more than it is guided on technical or practical grounds, and because the set of voters is far from being stable across all votings on R7RS-large dockets. Unanimous consent between those involved would be far better IMO, with one voting over the whole of the R7RS-large after consolidation. Another problem is that SRFIs are usually voted in all-or-nothing, but what's in a SRFI is eventually solely decided by its author. I will voice my support or objections for or against certain additions to the R7RS-large (if someone wants to listen), but I won't take part in the voting process anymore, using my democratic choice not to vote to document my opinion on the voting itself.
