Am Fr., 18. Okt. 2019 um 17:25 Uhr schrieb Lassi Kortela <xxxxxx@lassi.io>:

> Since Marc and John care about fast calls, would you accept the current
> compromise where the naive plist implementation is retained as the
> "least common denominator" compatible option, and if faster keywords are
> desired, the Scheme implementation is free to have a special calling
> convention?
>
> Thanks to everyone for all the thoughtful comments so far!

There's nothing for me to accept or refuse here. :) If a SRFI like
SRFI 177 is helpful to other Scheme programmers, it should be offered
to the community. The reasons why I have been a bit reserved may be
the summarized by the following (and, maybe, this can still be
addressed in a revised version of SRFI 177):

(1) Premature "standardization" of procedures with keywords. SRFI 177
is a compatibility layer over several native keyword systems (and a
fallback system). The semantics and syntax of SRFI 177 has been
dictated to make it implementable just with `syntax-rules'.

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.

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.

(2) Use of SRFI 177 in other SRFIs. As SRFI 177 won't probably be the
last word about procedures with keywords, I wouldn't want to see other
SRFIs (especially those intended to be included in R7RS-large)
dependent on SRFI 177. So far all libraries included in R7RS-large
have gotten along without keyword arguments, so I don't think that we
need and should invent APIs that are based on keyword arguments. This
is different to Python where keyword arguments are used all over (but
Python and its argument handling is slow, anyway).

(3) Some Scheme implementations are slow and cannot (or don't want to)
compete with C. For those, slower procedure call protocols may not
make much of a difference. On the other hand, we have implementations
like Chez. One reason why this implementation is so fast is because no
compromises are made when not necessary. Chez has `case-lambda' for
optional argument dispatch, but this can be made fast because by
giving not well-known procedures several entry points (one for zero,
one for one, one for two, etc. arguments) so that there is *no*
dispatch argument. I fail to see how this can work with arbitrary
keyword arguments.

(4) Keyword arguments as implemented by SRFI 177 are symbolic (as
opposed to hygienic (renamable) identifiers). This feels a bit
un-schemy and not in the trandition to where Scheme has gone since the
R6RS/R7RS. We have already had long discussions on the identifier
status of record field names and SRFI 159 has been revised into SRFI
166 because the state variables were (erroneously) symbolic.

In order to be able to macro-generate procedures with keyword
arguments (and without having to resort to `gensym') so that the
keyword arguments do not step on each other's toes, I think that the
keywords should become identifiers and not symbols in the long run as
well. This allows them to be matched hygienically with `syntax-rules'
(as much as `=>' and `else' are matched) but would disallow them to be
inspected/used during runtime.

--

Marc