Quick vote about portable keyword argument syntax
Lassi Kortela
(01 Nov 2019 19:44 UTC)
|
Re: Quick vote about portable keyword argument syntax
Marc Feeley
(01 Nov 2019 20:12 UTC)
|
The name of "keyword-call"
Lassi Kortela
(01 Nov 2019 20:45 UTC)
|
Re: The name of "keyword-call"
Lassi Kortela
(01 Nov 2019 20:51 UTC)
|
Re: The name of "keyword-call"
John Cowan
(01 Nov 2019 20:54 UTC)
|
Re: The name of "keyword-call"
Lassi Kortela
(01 Nov 2019 20:59 UTC)
|
Re: The name of "keyword-call"
John Cowan
(01 Nov 2019 21:30 UTC)
|
lambda*
Lassi Kortela
(01 Nov 2019 21:47 UTC)
|
Re: lambda*
John Cowan
(01 Nov 2019 21:48 UTC)
|
Re: lambda*
Lassi Kortela
(01 Nov 2019 21:59 UTC)
|
curry/partial
Lassi Kortela
(01 Nov 2019 22:18 UTC)
|
Re: curry/partial
John Cowan
(01 Nov 2019 22:47 UTC)
|
Re: The name of "keyword-call"
Marc Nieper-Wißkirchen
(02 Nov 2019 16:23 UTC)
|
Re: The name of "keyword-call"
Lassi Kortela
(02 Nov 2019 23:16 UTC)
|
Re: The name of "keyword-call"
hga@xxxxxx
(01 Nov 2019 21:34 UTC)
|
Re: Quick vote about portable keyword argument syntax
Per Bothner
(01 Nov 2019 20:57 UTC)
|
Re: Quick vote about portable keyword argument syntax
Lassi Kortela
(01 Nov 2019 21:06 UTC)
|
Re: Quick vote about portable keyword argument syntax
Marc Nieper-Wißkirchen
(02 Nov 2019 16:22 UTC)
|
Re: Quick vote about portable keyword argument syntax
Marc Nieper-Wißkirchen
(02 Nov 2019 16:42 UTC)
|
Re: Quick vote about portable keyword argument syntax
John Cowan
(02 Nov 2019 16:48 UTC)
|
Re: Quick vote about portable keyword argument syntax
Marc Nieper-Wißkirchen
(02 Nov 2019 16:57 UTC)
|
Re: Quick vote about portable keyword argument syntax
Lassi Kortela
(02 Nov 2019 23:28 UTC)
|
Re: Quick vote about portable keyword argument syntax
Lassi Kortela
(02 Nov 2019 23:47 UTC)
|
Re: Quick vote about portable keyword argument syntax
John Cowan
(03 Nov 2019 02:36 UTC)
|
Re: Quick vote about portable keyword argument syntax Marc Nieper-Wißkirchen (03 Nov 2019 08:49 UTC)
|
Re: Quick vote about portable keyword argument syntax
Lassi Kortela
(03 Nov 2019 09:56 UTC)
|
Re: Quick vote about portable keyword argument syntax
Marc Nieper-Wißkirchen
(03 Nov 2019 10:27 UTC)
|
Re: Quick vote about portable keyword argument syntax
Lassi Kortela
(03 Nov 2019 11:17 UTC)
|
Re: Quick vote about portable keyword argument syntax
Marc Nieper-Wißkirchen
(03 Nov 2019 11:31 UTC)
|
Re: Quick vote about portable keyword argument syntax
Lassi Kortela
(03 Nov 2019 12:41 UTC)
|
Re: Quick vote about portable keyword argument syntax
Marc Nieper-Wißkirchen
(03 Nov 2019 15:20 UTC)
|
Re: Quick vote about portable keyword argument syntax
Lassi Kortela
(03 Nov 2019 15:40 UTC)
|
Re: Quick vote about portable keyword argument syntax
Lassi Kortela
(03 Nov 2019 15:50 UTC)
|
Re: Quick vote about portable keyword argument syntax
John Cowan
(03 Nov 2019 19:39 UTC)
|
Am So., 3. Nov. 2019 um 00:47 Uhr schrieb Lassi Kortela <xxxxxx@lassi.io>: > > >> How do you want > >> > >> (let ((:e 3)) > >> (keyword-call foo 1 2 :e 4)) > >> > >> being handled? > > The `e` keyword argument would get the value 4. > > The `keyword-call` macro would have to be implemented using syntax-case, > explicit renaming or define-macro. It would scan the list for things > that are symbols at read time, and whose names start or end with a > colon. It would then take the name without the colon, and use that as > the keyword's name. The lexical binding (if any) of the symbol would > simply be ignored; the symbol would be used for its name only. Please, don't let us standardize this behavior (maybe as a hack until we have proper keywords, but not for inclusion into R7RS-large). This would be just a wart in the Scheme language, destroying Scheme's uniformity. Local bindings shadow every identifier, whether bound to variables, to macro keywords, pattern variables, or whatever. For example, even the ellipsis can be shadowed by a local binding (the following expression is not an error but evaluates to the symbol foo): (let ((... 'foo)) (define-syntax bar (syntax-rules () ((bar) ...))) (bar)) Option 2 would destroy part of Scheme's simplicity through uniformity. > > To use the binding of `:e` as 3, the following workaround can be used: > > (let ((:e 3)) > (keyword-call foo 1 2 (values :e) 4)) > > Since the macro does not look inside sublists, (values) can be used to > "protect" arguments from it :) > > >> While Option 2 looks much better than Option 1, it doesn't seem to > >> work well when the underlying Scheme does not have a separate keyword > >> type (and keyword syntax). > > In those Schemes it relies completely on colons in the symbol names. I > don't think that's a big problem, as colons in names are almost never > used except for keyword arguments, having `call/kw` as the head of the > list clearly shows that some magic is going on, and (values) can be used > for any workarounds. It's also not safe to use symbols with colons in > portable Scheme code, since many Schemes interpret them as keywords. So > I don't think programmers lose any useful symbol names that way. > > The one case that option 2 handles very poorly, is hygienic keywords. If > those are referred to as plain symbols (e.g. just `foo` with no colon), > they are not distinguishable from ordinary symbols that are used to get > the value of some variable from the lexical environment. I can't think > of a reasonable way to solve that ambiguity. > > >> So what about the following Option 3? > >> > >> (keyword-call foo 1 2 : e 5) > >> > >> In Schemes with a keyword reader syntax, it can be expressed as > >> > >> (keyword-call foo 1 2 #:e 5) > > Do you mean that in the case of more than one keyword argument, the > colon would be repeated like this: > > (keyword-call foo 1 2 : e 5 : f 6 : g 7) Both options are possible (so we have an Option 4) if positional and keyword arguments do not have to be mixed. > That's certainly possible, but I imagine it doesn't look very familiar > to people, and they would keep typing the colon and keyword name > together (without a space in between) out of habit, since that's what's > done in many/most Lisps with keywords. I don't think we would demand too much from the average Scheme programmer. In the long term, we can hope that "#:key" will be standardized, creating a new type of Scheme object that does not clash with the semantics of identifiers. > > This also doesn't make it obvious what to do about hygienic vs > non-hygienic keywords. Would : use a hygienic keyword, and :: (two > colons) a non-hygienic one? Or vice versa. We are stuck with the same > problems that we have if there is no space after the colon. > > I guess one more alternative would be having only one delimiter: > > (keyword-call foo 1 2 : e 5 f 6 g 7) > > That's very similar to the originally proposed syntax of having the > keyewords in a list, but IMHO less clear: > > (keyword-call foo 1 2 (e 5 f 6 g 7)) > > >> Option 3 is also implementable using syntax-rules alone. > > That's very nice, but is that true? Is it able to match the ': symbol at > the start of a list? As John wrote, : would exported by SRFI 177 and call/kw would compare to the binding of :. > > > P.S.: > > > > And keyword-lambda (lambda/kw) could be: > > > > (lambda/kw (a b c : e x <default> ...) > > ...) > > IMHO this is almost equivalent to the originally proposed (lambda/kw (a > b c (e x)) ...) but more complex. It's certainly a possibility though.