Am So., 3. Nov. 2019 um 11:54 Uhr schrieb Lassi Kortela <xxxxxx@lassi.io>:
>
> >> My argument for that is just compatibility and uniformity. For example,
> >> if an RnRS procedure is extended with keyword arguments, that can't be
> >> done in a compatible way if the keyword procedure cannot act like a
> >> normal procedure in every way.
> >
> > In R6RS, it can be done with identifier syntax.
>
> Do you mean that e.g. `open-output-file` as an identifier would evaluate
> to a genuine lambda, whereas `(open-output-file ...)` would be a macro
> that expands to the keyword argument checking and finally a fast call to
> a lambda?

Yes, this is possible and all that would be needed if we do not treat
keyword arguments as first class objects (that can be forwarded).

>
> The current text of 177 says that `keyword-lambda` and `keyword-call`
> are "syntax". But I have nothing against them being special primitive
> operators either. Is there particular language we can use in the SRFI to
> say that? I think "special operator" is a Common Lisp term.

R7RS-small uses the terms "expression type" and "syntax". What would
"special primitive operator" add?

> > As soon as we have syntax-case (or identifier syntax for
> > er-macro-transformers) in R7RS, it can also be done there. (And the
> > "Option 2" syntax already needs more than is in syntax-rules.)
>
> That's true. You and John have convinced me to relax the requirement on
> syntax-rules compatibility :)
>
> > Maybe you could explain to me why it is so important that the
> > implementation of SRFI 177 builds upon the native keyword argument
> > system whenever one is present. This way we will end up only with the
> > least common denominator. But for what purpose?
>
> The motivation that spurred 177 was: Uf a Scheme library writer wants to
> start using keyword arguments in their libraries today, how could we let
> them do that? I probably didn't explain this motivation clearly enough
> in the SRFI rationale; sorry about that.
>
> Present compatibility sets quite different requirements than something
> where we are only working toward future R7RS standardization. It means
> we can't use any syntax or semantics that require upgrading existing
> implementations or waiting for a new standard to be ratified. It has to
> be implementable only using macros in existing implementations.
>
> My primary interest with Scheme is portable code (between R6RS and R7RS,
> and also between implementations that loosely implement those standards
> but don't conform to every detail). From that perspective, doing keyword
> args that are fully compatible with all existing native kw args, and the
> only compromise is magic :foo and foo: symbols, is a huge win.
>
> I understand that from a purity standpoint such hacks are suspect.
> That's why I want to design 177 in such a way that it can be replaced
> with a cleaner alternative later. But however it is done, 177 has to be
> something that is usable today, without upgrading implementations,
> simply by loading a library.

The current version of SRFI 177 has a portable sample implementation
(possibly depending on some low-level macro system), so native keyword
arguments do not have to present. Thus I don't see why, for the
purpose of SRFI 177, we have to be able to build upon them when they
are present.

> > What has to be done (and is being done:)) is to look at the various
> > native systems to get the best ideas. Then all it has to be made sure
> > that it isn't too hard to implement SRFI 177 on the most relevant
> > Scheme systems.
>
> This is very good as long as we have a "tower" of increasingly
> sophisticated semantics, so that each level of the tower is a compatible
> superset of all the lower levels.
>
> 177 is meant to be the lowest level of the tower: just unhygienic
> keyword args, all of them optional, with #f default values. The simplest
> useful thing.
>
> But those semantics are a subset of the upper levels of the tower:
> hygienic keyword args, default values, supplied-p parameters,
> allow-other-keys, etc.
>
> That means a library writer can pick the lowest level that fulfills
> their requirements. Many libraries don't need anything fancier than
> global keywords with #f defaults; they can use 177. If someone needs to
> write wrappers that handle unfamiliar keywords, they can use the
> hypothetical SRFI 178 with allow-other-keys. If someone needs something
> even fancier, they can import that, etc.
>
> The point is that at any time, the writer of a library picks the
> most-widely-compatible thing that works. That ensures the library can be
> enjoyed by as many Schemers as possible.
>
> R7RS-small compatibility is very important from this standpoint, as is
> continued R6RS compatibility. R7RS-large can more freely make a choice
> about its approach to the keyword tower. But whatever choice it makes,
> should have semantics that are compatible with the other alternatives.

I do not argue against this, not at all. :) But R7RS-small and R6RS
compatibility do not demand that we have to compatible (what does it
mean, by the way) with ad-hoc native keyword systems.

May I propose, before finalization of SRFI 177, to spec a, say, SRFI
178 first. SRFI 178 shall be a proposal for keyword arguments in a
future R7RS-large version that has more freedom.

I would like to see a clear upgrade path from SRFI 177 to such a SRFI
178 so that SRFIs that initially build upon SRFI 177 work with SRFI
178 as well and in the most natural way.

-- Marc