Email list hosting service & mailing list manager

Re: Wrapping up SRFI 177: Portable keyword arguments John Cowan (02 Mar 2020 23:53 UTC)
Re: Wrapping up SRFI 177: Portable keyword arguments Marc Feeley (03 Mar 2020 04:46 UTC)
Re: Wrapping up SRFI 177: Portable keyword arguments Marc Nieper-Wißkirchen (03 Mar 2020 06:29 UTC)
Re: Wrapping up SRFI 177: Portable keyword arguments Marc Nieper-Wißkirchen (03 Mar 2020 06:43 UTC)
Re: Wrapping up SRFI 177: Portable keyword arguments Marc Nieper-Wißkirchen (03 Mar 2020 07:51 UTC)
Identifier syntax, and using macros with call/kw Lassi Kortela (03 Mar 2020 08:57 UTC)
Re: Identifier syntax, and using macros with call/kw Shiro Kawai (03 Mar 2020 09:00 UTC)
Re: Identifier syntax, and using macros with call/kw Marc Nieper-Wißkirchen (03 Mar 2020 09:06 UTC)
Re: Identifier syntax, and using macros with call/kw Shiro Kawai (03 Mar 2020 09:19 UTC)
Re: Identifier syntax, and using macros with call/kw Marc Nieper-Wißkirchen (03 Mar 2020 09:48 UTC)
Re: Identifier syntax, and using macros with call/kw Shiro Kawai (03 Mar 2020 10:03 UTC)
Re: Identifier syntax, and using macros with call/kw Marc Nieper-Wißkirchen (03 Mar 2020 10:12 UTC)
Re: Identifier syntax, and using macros with call/kw John Cowan (06 Oct 2020 20:20 UTC)
Re: Identifier syntax, and using macros with call/kw Marc Nieper-Wißkirchen (07 Oct 2020 07:29 UTC)
Syntax for identifier syntax Lassi Kortela (03 Mar 2020 09:55 UTC)
Re: Syntax for identifier syntax Marc Nieper-Wißkirchen (03 Mar 2020 10:16 UTC)
Re: Syntax for identifier syntax John Cowan (03 Mar 2020 13:37 UTC)
Re: Syntax for identifier syntax Lassi Kortela (03 Mar 2020 13:42 UTC)
Re: Syntax for identifier syntax Marc Nieper-Wißkirchen (03 Mar 2020 14:59 UTC)
Re: Syntax for identifier syntax Jim Rees (04 Mar 2020 18:12 UTC)
Re: Syntax for identifier syntax Marc Nieper-Wißkirchen (04 Mar 2020 18:18 UTC)
Re: Syntax for identifier syntax John Cowan (04 Mar 2020 23:48 UTC)
Re: Identifier syntax, and using macros with call/kw Marc Nieper-Wißkirchen (03 Mar 2020 09:13 UTC)
R7RS-large backward compatibility Lassi Kortela (03 Mar 2020 10:31 UTC)
Re: R7RS-large backward compatibility Marc Nieper-Wißkirchen (03 Mar 2020 11:31 UTC)
Specifying a meeting point for different keyword systems Lassi Kortela (03 Mar 2020 11:56 UTC)
Re: Specifying a meeting point for different keyword systems Marc Nieper-Wißkirchen (03 Mar 2020 15:03 UTC)
Re: R7RS-large backward compatibility John Cowan (05 Mar 2020 19:36 UTC)
Re: R7RS-large backward compatibility Lassi Kortela (05 Mar 2020 19:51 UTC)
Re: R7RS-large backward compatibility John Cowan (05 Mar 2020 20:03 UTC)
Re: R7RS-large backward compatibility Lassi Kortela (05 Mar 2020 20:17 UTC)
Re: R7RS-large backward compatibility Marc Nieper-Wißkirchen (08 Mar 2020 09:00 UTC)
Re: R7RS-large backward compatibility Lassi Kortela (08 Mar 2020 09:06 UTC)
Re: R7RS-large backward compatibility John Cowan (08 Mar 2020 21:58 UTC)
Re: R7RS-large backward compatibility Lassi Kortela (08 Mar 2020 22:40 UTC)
Re: [scheme-reports-wg2] Re: R7RS-large backward compatibility Marc Nieper-Wißkirchen (09 Mar 2020 07:42 UTC)
Re: [scheme-reports-wg2] Re: R7RS-large backward compatibility Marc Nieper-Wißkirchen (09 Mar 2020 11:46 UTC)
Re: [scheme-reports-wg2] R7RS-large backward compatibility Lassi Kortela (09 Mar 2020 12:07 UTC)
Re: R7RS-large backward compatibility Per Bothner (09 Mar 2020 16:30 UTC)
Re: [scheme-reports-wg2] Re: R7RS-large backward compatibility Marc Nieper-Wißkirchen (09 Mar 2020 16:48 UTC)

Specifying a meeting point for different keyword systems Lassi Kortela 03 Mar 2020 11:55 UTC

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