Thus, the semantics and syntax of SRFI 177 are probably far from
optimal if we had the chance to devise it from scratch (as opposed to
be a common denominator, portably implementable in R5RS). Should ever
become procedures with keyword arguments candidates for inclusion into
R7RS-large (or some other future standard), we should be free to
invent semantics and syntax that may be incompatible with SRFI 177.
IMO it is this belief that caused the uptake of R6RS to be so limited. Only four Schemes that existed before R6RS was published have adopted it: Chez, Racket, Larceny, and Guile. Implementers of the first three were on the R6RS committee (Will Clinger took his name off because of strong disagreements with the product, especially in the area of MUSTard). What is more, Larceny and Guile implement R6RS in a relaxed way best described in Clinger's paper "R7RS Considered Unifier of Previous Standards" <
http://www.schemeworkshop.org/2015/sfpw1-2015-clinger.pdf>.
In principle, standards committees should never invent anything, just standardize what has already been widely adopted. That isn't practical in Scheme, but I have still done my damnedest to make sure there was a model of some kind somewhere for almost all the R7RS-large SRFIs I have written, and so far all of them except SRFI-170 have portable implementations (there will be more later that do not). That meant that implementers, who don't like changing things much (and especially core things) are willing to adopt them, and if they aren't, their users can do so directly.
Messing with lambda binding is a deep change, comparable to the single standard R6RS provided for exceptions. It would have been too much work to adopt them in full, and even Racket wound up with a traditional and an R6RS exception system. Just the issue of what exception to raise when and what the exception hierarchy was going to be provoked a lot of resistance. I hope to have a partially-standardized condition system in R7RS-large that will fit over existing ones in the way that SRFI 177 fits over existing keyword systems. The goal of R7RS-large is to put vetted modules into people's hands that make development easy: writing large problems in portable Scheme is currently a lot like assembling a model ship inside a bottle.
Also, if some procedural macro system like `syntax-case' becomes more
widespread (say because of inclusion in R7RS-large), we may want to
revisit SRFI 177 because it would allow more syntactic freedom when
specifying the interface.
Well, I think the news on that front is pretty good, and while I personally am no fan of any low-level macro system, the holdouts against syntax-case are now very few among those systems that have low-level hygienic macros at all: MIT, Chicken, and Gauche are the only holdouts.
Unfortunately, the Chibi syntax-case layer depends on syntactic closures, whereas Chicken and Gauche only provide explicit renaming. (Syntactic closure support is rare: MIT, Chibi, Picrin.)
This is different to Python where keyword arguments are used all over (but
Python and its argument handling is slow, anyway).
How fast it is depends on the implementation; the fallback syntax-rules implementation is of course slow.
One reason why this implementation is so fast is because no
compromises are made when not necessary.
A Chez-specific implementation should certainly use syntax-case if it helps any.
I think Shiro's responses to 3 and 4 are compelling.
John Cowan
http://vrici.lojban.org/~cowan xxxxxx@ccil.orgThe present impossibility of giving a scientific explanation is no proof
that there is no scientific explanation. The unexplained is not to be
identified with the unexplainable, and the strange and extraordinary
nature of a fact is not a justification for attributing it to powers
above nature. --The Catholic Encyclopedia, s.v. "telepathy" (1913)