Email list hosting service & mailing list manager

Keywords reduced Lassi Kortela (18 Oct 2019 15:24 UTC)
Re: Keywords reduced John Cowan (18 Oct 2019 20:48 UTC)
Re: Keywords reduced Lassi Kortela (18 Oct 2019 22:24 UTC)
Re: Keywords reduced Marc Nieper-Wißkirchen (19 Oct 2019 08:25 UTC)
Re: Keywords reduced John Cowan (19 Oct 2019 19:04 UTC)
Re: Keywords reduced Marc Nieper-Wißkirchen (20 Oct 2019 09:15 UTC)
Re: Keywords reduced John Cowan (21 Oct 2019 17:26 UTC)
Re: Keywords reduced Marc Nieper-Wißkirchen (21 Oct 2019 18:37 UTC)
Re: Keywords reduced Shiro Kawai (21 Oct 2019 19:27 UTC)
Re: Keywords reduced Marc Nieper-Wißkirchen (22 Oct 2019 06:04 UTC)
Re: Keywords reduced Shiro Kawai (22 Oct 2019 10:07 UTC)
Re: Keywords reduced John Cowan (22 Oct 2019 19:33 UTC)
Re: Keywords reduced John Cowan (22 Oct 2019 19:38 UTC)
Re: Keywords reduced Lassi Kortela (22 Oct 2019 20:06 UTC)
Syntactic keywords vs parentheses Lassi Kortela (22 Oct 2019 20:30 UTC)
Re: Syntactic keywords vs parentheses John Cowan (22 Oct 2019 20:54 UTC)
Re: Syntactic keywords vs parentheses Lassi Kortela (22 Oct 2019 21:07 UTC)
Re: Syntactic keywords vs parentheses Shiro Kawai (22 Oct 2019 22:24 UTC)
Re: Syntactic keywords vs parentheses Lassi Kortela (23 Oct 2019 07:40 UTC)
Re: Syntactic keywords vs parentheses John Cowan (22 Oct 2019 23:12 UTC)
Re: Syntactic keywords vs parentheses Amirouche Boubekki (25 Oct 2019 11:55 UTC)
Re: Keywords reduced Marc Nieper-Wißkirchen (23 Oct 2019 07:18 UTC)
Re: Keywords reduced John Cowan (21 Oct 2019 23:06 UTC)
Re: Keywords reduced Shiro Kawai (22 Oct 2019 00:42 UTC)
Re: Keywords reduced Marc Nieper-Wißkirchen (22 Oct 2019 06:12 UTC)
Re: Keywords reduced Lassi Kortela (22 Oct 2019 10:56 UTC)
Re: Keywords reduced Lassi Kortela (20 Oct 2019 09:42 UTC)
Remaining keyword problems Lassi Kortela (29 Oct 2019 17:59 UTC)
allow-other-keys Lassi Kortela (29 Oct 2019 18:29 UTC)
Re: allow-other-keys John Cowan (29 Oct 2019 18:55 UTC)
Re: allow-other-keys Shiro Kawai (29 Oct 2019 19:18 UTC)
Re: allow-other-keys Lassi Kortela (29 Oct 2019 23:04 UTC)
Re: allow-other-keys Marc Feeley (29 Oct 2019 21:05 UTC)
Re: allow-other-keys Marc Nieper-Wißkirchen (03 Nov 2019 08:16 UTC)
Re: allow-other-keys Lassi Kortela (03 Nov 2019 10:11 UTC)
Re: allow-other-keys Marc Nieper-Wißkirchen (03 Nov 2019 10:34 UTC)
Re: allow-other-keys Lassi Kortela (03 Nov 2019 10:54 UTC)
Re: allow-other-keys Marc Nieper-Wißkirchen (03 Nov 2019 11:13 UTC)
Re: allow-other-keys Lassi Kortela (03 Nov 2019 11:39 UTC)
Re: allow-other-keys Arthur A. Gleckler (03 Nov 2019 18:39 UTC)
Re: allow-other-keys Marc Nieper-Wißkirchen (03 Nov 2019 18:47 UTC)
Re: allow-other-keys John Cowan (03 Nov 2019 19:20 UTC)
Re: allow-other-keys John Cowan (03 Nov 2019 19:18 UTC)
Re: allow-other-keys Marc Nieper-Wißkirchen (03 Nov 2019 19:51 UTC)
Re: allow-other-keys John Cowan (03 Nov 2019 22:19 UTC)
Identifier syntax and the range of Schemes to support Lassi Kortela (03 Nov 2019 19:54 UTC)
Re: Remaining keyword problems John Cowan (29 Oct 2019 19:51 UTC)
Re: Remaining keyword problems Lassi Kortela (29 Oct 2019 21:09 UTC)
Alternative syntax using colon symbols for portable keywords Lassi Kortela (29 Oct 2019 22:29 UTC)
Re: Remaining keyword problems Marc Nieper-Wißkirchen (11 Nov 2019 14:56 UTC)
Re: Remaining keyword problems Lassi Kortela (11 Nov 2019 16:15 UTC)
Re: Remaining keyword problems Marc Nieper-Wißkirchen (11 Nov 2019 14:44 UTC)
Re: Remaining keyword problems John Cowan (11 Nov 2019 16:48 UTC)
Re: Remaining keyword problems Marc Nieper-Wißkirchen (11 Nov 2019 17:06 UTC)
Re: Remaining keyword problems John Cowan (11 Nov 2019 17:15 UTC)
Re: Keywords reduced Shiro Kawai (19 Oct 2019 09:25 UTC)
Re: Keywords reduced Lassi Kortela (19 Oct 2019 09:38 UTC)
Re: Keywords reduced Marc Nieper-Wißkirchen (19 Oct 2019 12:22 UTC)
Re: Keywords reduced Shiro Kawai (19 Oct 2019 18:43 UTC)
Re: Keywords reduced Marc Nieper-Wißkirchen (20 Oct 2019 08:39 UTC)
Re: Keywords reduced Lassi Kortela (20 Oct 2019 09:28 UTC)
Re: Keywords reduced Shiro Kawai (20 Oct 2019 10:12 UTC)
Re: Keywords reduced Shiro Kawai (20 Oct 2019 10:17 UTC)
Re: Keywords reduced Lassi Kortela (20 Oct 2019 10:22 UTC)
Re: Keywords reduced Shiro Kawai (20 Oct 2019 10:41 UTC)
Re: Keywords reduced Marc Nieper-Wißkirchen (20 Oct 2019 21:10 UTC)
Re: Keywords reduced Shiro Kawai (20 Oct 2019 21:19 UTC)
Re: Keywords reduced Marc Nieper-Wißkirchen (20 Oct 2019 21:33 UTC)
Re: Keywords reduced Shiro Kawai (20 Oct 2019 22:05 UTC)
Re: Keywords reduced Marc Nieper-Wißkirchen (21 Oct 2019 07:01 UTC)
Re: Keywords reduced Shiro Kawai (20 Oct 2019 22:18 UTC)
Re: Keywords reduced Marc Nieper-Wißkirchen (21 Oct 2019 07:05 UTC)
Re: Keywords reduced Shiro Kawai (21 Oct 2019 07:24 UTC)
Re: Keywords reduced Marc Nieper-Wißkirchen (20 Oct 2019 21:04 UTC)
Re: Keywords reduced Shiro Kawai (20 Oct 2019 21:41 UTC)
Re: Keywords reduced Marc Nieper-Wißkirchen (21 Oct 2019 06:49 UTC)
Re: Keywords reduced Shiro Kawai (21 Oct 2019 07:52 UTC)
Re: Keywords reduced Marc Nieper-Wißkirchen (21 Oct 2019 11:46 UTC)
Re: Keywords reduced Peter Kourzanov (21 Oct 2019 15:42 UTC)
Re: Keywords reduced Marc Nieper-Wißkirchen (21 Oct 2019 15:54 UTC)
Re: Keywords reduced Shiro Kawai (21 Oct 2019 17:38 UTC)
Re: Keywords reduced John Cowan (21 Oct 2019 17:45 UTC)
Re: Keywords reduced Lassi Kortela (22 Oct 2019 08:21 UTC)
Keywords vs paremeters for hygiene Lassi Kortela (21 Oct 2019 08:05 UTC)
Re: Keywords vs paremeters for hygiene Marc Nieper-Wißkirchen (21 Oct 2019 11:22 UTC)

Re: allow-other-keys Lassi Kortela 03 Nov 2019 10:54 UTC

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

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.

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

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