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 11:39 UTC

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

It's worth thinking about this from a reflection standpoint too. Though
Scheme is designed with a focus on compilation, and reflection doesn't
need to be standardized in RnRS, is very useful in several implementations.

It should be possible to get the full argument list of a keyword
procedure if an implementation wants to provide that (for code
completion, etc.) If the identifier-syntax evaluates to a first-class
procedure, maybe the procedure object can have some
implementation-defined metadata tagged onto it. But then you can't call
that object with the keywords. Well, there could still be a separate
call-kw-object macro. Here the semantics start to get more complicated
when we deviate from standard lambdas; that's why my intuition suggested
staying with them. But all of this is still possible to handle in principle.

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

If "syntax" includes both macros and special operators, then "syntax" is
fine. I was worried that term would only mean macros :)

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

To take advantage of the work that 10 Scheme implementors have already
put into Scheme. If we have two incompatible keyword systems, that's
unfortunately the kind of thing that outsiders make jokes about :(

It's moderately bad that 177 already has different _syntax_ compared to
the implementation-native ones. We can alleviate that by making the 177
syntax look as similar to the existing ones as possible, which is why
"option 2" in the other thread was so popular.

But if we introduce incompatible _semantics_, so that the portable and
native keyword systems cannot talk to each other, I would have a hard
time explaining to programmers outside Scheme why that is a good idea.

I think the starting point should be that if e.g. Gauche implements
R7RS-large, then Gauche's native keyword arguments used in its built-in
procedures are instantly compatible with R7RS-large keyword arguments.
This leverages the existing work of all implementors who are using
keywords so far, and is less confusing to new Scheme programmers.

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

IMHO ad hoc is not a fitting expression for them; they've been in Lisp
since the eighties and have been in extremely wide use in applications
and libraries of all kinds.

To me, compatibility means that procedures defined using keyword-lambda
syntax A can be called using keyword-call syntax B, and vice versa. 177
currently keeps this promise for all known Scheme implementations.

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

That may be a good idea. We should ask Arthur about the timeline for 177
finalization. I don't mind waiting some more to ensure we do a good job.

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

Agreed!