Am Mo., 26. Juli 2021 um 13:43 Uhr schrieb John Cowan <[email protected]>:
> > > On Mon, Jul 26, 2021 at 2:10 AM Marc Nieper-Wißkirchen < > [email protected]> wrote: > > Bound-identifier=? is what is needed. Free-identifier=? roughly is the >> COMPARE argument to er-macro-transformer. >> > > Yes, sorry. I had a 50% chance of guessing right. > No problem. I am prone to exactly the same 50% mistakes. I just wanted to get it right for the record. > There's a new draft of SRFI 211 and I plan on getting it finalized soon. >> Feedback would be very welcome, of course. >> > > I can't comment on the substance because I can barely handle > syntax-rules. But a minor point and a major one: > > 1) The "old-style Lisp" macros should be called "Common Lisp" macros, > because Scheme is also a Lisp, and because defmacro/define-macro is not > "old style" to Common Lispers and various kinds of Schemers too. > Thanks. I will improve the language. The language that's currently in SRFI 211 comes from the R6RS. > SRFIs normally give a user-directed specification of what these things do, > and put the implementation strategy into the non-normative "Implementation" > section. This SRFI is almost all implementation strategy. > Can you clarify what you mean? I don't think I say anything about how to implement these things. > Although probably futile, I repeat my objection against the voting > process, which I don't think produces the best language possible. > > Saying "best" leads to the question "Best as decided by whom?" and in turn > "Best for whom?" > I know that my comments and language like "best" are rightfully arguable. I think we have had this discussion once: I believe that in confined areas there is some absolute notion of what is best. To give a trivial example: That the objects of SRFI 217 are prefixed with "i" and the objects of SRFI 224 are prefixed with "fx" is certainly not the best outcome (this may be corrected, of course). If global language changes (including revoting, consolidating, and amending SRFIs) will be allowed and will happen extensively at the end of the R7RS-large design process, my objections here may be moot. 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, >> > > Inevitably so. You (and I, for that matter) know a great deal about a > great deal, but are not *fully* informed in that sense. > For sure! I know quite a number of SRFIs on which I have voted for the Red and Tangerine edition and which (and whose direct and indirect implications) I think I didn't fully understand when I voted. Even in areas where I think I know a lot, I am always surprised how much there is still to understand and learn. > because the set of voters is far from being stable across all votings on >> R7RS-large dockets. >> > > That too I believe to be inevitable in a multi-year project, whether the > self-appointed deciders use STV + majority vote or unanimity. R7RS-large > is the first standard I know of at this scale that wasn't written by people > whose employers paid them to write it, as was the case for Java (844 pages) > or CL (1360 pages). We all work on it part-time with a variable amount of > our total effort. > That obviously raises the question of whether some funding could be found. > Consequently, we can maintain no schedule, and people will come and go: > they may lose interest, change to a more demanding job, have to drop out > for personal or family reasons, decide to do nothing further for the > project because of deep objections to how it's going (Will Clinger's case > with R6RS) or just plain die. (I don't expect to see this project through > to the end, and I hope that if it is ever finished it will be dedicated to > my memory.) > While the latter would be certainly very much so, the whole last sentence sounds a bit sad. I hope you'll be able to experiment with the first fully (or mostly fully) conformant R7RS-large implementation, whatever it will be. > 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. >> > > People who wish to do otherwise need only write their own SRFIs, which can > be and often are based on existing SRFIs or other documents. > Unfortunately, this is not happening in reality. No one writes a new SRFI that is 98% equivalent to an existing SRFI but gets the remaining 2% "right" in the sense of the second author. The R6RS took the approach of withdrawing SRFIs once they became part of the R6RS. This had the huge advantage that from that point on it could be massaged and amended to fit together with the other parts. (But I should not sweep one disadvantage under the table: These SRFIs are now lost to the non-R6RS SRFI process. Who is using SRFI 93, for example? For that, one would have to check first whether and what changes there have been between SRFI 93 and R6RS's syntax-case, etc.) > 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. >> > > ~~ sigh ~~. Since it must be so. > I'm not saying that I can't be convinced. But I find it would be inconsequential to criticize the voting process and then trying to get my opinion through it.
