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 Marc Nieper-Wißkirchen 03 Nov 2019 11:13 UTC

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