Am Sa., 19. Okt. 2019 um 21:04 Uhr schrieb John Cowan <xxxxxx@ccil.org>:
>
>
>
> On Sat, Oct 19, 2019 at 4:26 AM Marc Nieper-Wißkirchen <xxxxxx@nieper-wisskirchen.de> wrote:
>
>> 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.
>

Maybe you misunderstood me because I didn't explain myself clearly
enough or I misinterpreted you. :)

I didn't want to suggest to invent something completely new and what
couldn't be rather easily implemented by existing Schemes.
Nevertheless, some new syntax or protocol for keyword arguments has to
be invented because the existing keyword argument systems differ. SRFI
177 in its current shape is one of such invention, which abstracts
over the existing systems. What I wanted to express is that later
additions to the R7RS-large might make possibly better
abstractions/syntax possible. At least for R7RS-large it does not seem
to make sense to me to restrict ourselves to syntax that can be
portably implemented with `syntax-rules' until we haven't decided on
the macro system of R7RS-large.

>> 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.)

What do you mean by "unfortunately"? Explicit renaming in Chibi is
just a thin layer over syntactic closures and while `syntax-case'
cannot be implemented on top of explicit renaming or syntactic
closures, it can after slight modifications. (That said, Dybvig's
original marks-and-substitutions algorithm still has the best
asymptotic running time behavior.)

>
>> 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.org
> The 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)
>

--
Prof. Dr. Marc Nieper-Wißkirchen

Universität Augsburg
Institut für Mathematik
Universitätsstraße 14
86159 Augsburg

Tel: 0821/598-2146
Fax: 0821/598-2090

E-Mail: xxxxxx@math.uni-augsburg.de
Web: www.math.uni-augsburg.de/alg/mitarbeiter/mnieper/