Email list hosting service & mailing list manager

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)

Re: Quick vote about portable keyword argument syntax Lassi Kortela 02 Nov 2019 23:47 UTC

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

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)

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.

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?

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