I like your initiative!

We just have to keep in mind that there is one caveat: As the protocol is not specified, it means that there are no portable implementations of any SRFI implementing the protocol. For example, the implementation of SRFI 177 has to use for each Scheme implementation the right protocol.

This can possibly be remedied by a very low-level interface (which will be Scheme implementation specific), on which high-level interfaces like SRFI 177 can build.

Marc

Am Di., 3. März 2020 um 12:56 Uhr schrieb Lassi Kortela <xxxxxx@lassi.io>:
> I understand your point that SRFI 177 shall be compatible with existing
> keyword systems as far as this is feasible.

Thanks. Indeed, the major advantage of the current draft is that it's
compatible with all existing ones. But there may be other approaches
that are compatible as well.

> But we also have to make sure that SRFI 177 is compatible with whatever
> SRFI about keyword arguments that will finally make it into R7RS-large.
> As we don't know that SRFI yet, we may have to be a bit conservative.

Agreed. It would be sad if 177 ends up incompatible with R7RS-large.

> To me, now the question comes up how to write specifications for SRFIs
> that want to make use of keyword arguments. There implementation may
> depend on a specific system like SRFI 177, but the interface should be
> opaque.
>
> How would you write this?

I would not make those SRFIs depend on 177, but would simply talk about
"keyword arguments" in without referring to a particular keyword SRFI.

> A related question is: How can we make sure that if we have two
> implementations of a keyword system, say of SRFI 177 and of SRFI 277, in
> a Scheme system, they can talk to each other?

It's good that you bring this up again now that we have explored more
alternatives.

We should probably write a document that is even shorter and simpler
than SRFI 177, specifying a minimal set of guarantees given by Scheme
implementations and future standards for keyword arguments. It would
specify something like:

1. it's possible to make a procedure taking optional keyword arguments,
default value #f.

2. other kinds of keyword arguments may be possible as well, but they
are compatible with point 1.

3. the implementation provide one or more systems that can define and
call keyword procedures. keyword procedures conforming to point 1,
defined using any of those systems, can be called via any other one of
the systems.

So it would give the bare minimum that lets people write SRFIs using
keywords, confident that implementations and R7RS-large will keep the
interoperability promise.

Meanwhile, R7RS-large and implementations would be free to explore more
sophisticated keyword systems as long as they can express a subset that
is compatible with the promise.

Having an explicit promise like this would probably be good for
everyone's peace of mind, would give clarity to specification efforts,
and would let us start writing SRFIs making simple use of keyword args
without fear of future incompatibility.

How would this sound?


--
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/