Email list hosting service & mailing list manager

Read syntax for hygienic keywords Lassi Kortela (20 Oct 2019 10:34 UTC)
Re: Read syntax for hygienic keywords Shiro Kawai (20 Oct 2019 12:32 UTC)
Re: Read syntax for hygienic keywords Marc Nieper-Wißkirchen (20 Oct 2019 21:23 UTC)
Re: Read syntax for hygienic keywords Lassi Kortela (21 Oct 2019 08:27 UTC)
Re: Read syntax for hygienic keywords Per Bothner (21 Oct 2019 23:27 UTC)

Re: Read syntax for hygienic keywords Marc Nieper-Wißkirchen 20 Oct 2019 21:23 UTC

Am So., 20. Okt. 2019 um 12:34 Uhr schrieb Lassi Kortela <xxxxxx@lassi.io>:
>
> Continuing from Marc's intriguing idea in the last thread, how would we
> have portable syntax for hygienic keywords?
>
> SRFI 177 keyword-call is just a portable stopgap measure; for a
> language's native syntax, something like this is probably better:
>
> (foo a b #:key1 c #:key2 d)
>
> The question then arises: how do you make those hygienic?
>
> Maybe like this:
>
> (foo a b #:(hygienic key1) c #:(hygienic key2) d)
>
> Or use a different prefix for hygienic and unhygienic keywords.

I don't think that we would need an extra prefix for hygienic keywords:

In R7RS, everything like `foo', `:foo', and `foo:' is read as a symbol
by the reader so ends up being an identifier (except for when
appearing in literals). So reader extensions are just needed so that
representations like `:foo' or `foo:' are read as keyword objects.

But they are not necessarily needed for procedures with keyword
arguments. For example,

(foo a b #:key1 c #:key2 d)

could be equivalent to:

(foo a b (symbol->keyword 'key1) c (symbol->keyword 'key2) d)

if keyword objects in argument positions are not recognized as
ordinary values but as markers.

On the other, if `key1' and `key2' are bound as identifiers (!) to
keywords (in the sense of some version of SRFI 177), the following

(foo a b key1 c key2 d)

can still mean that `c' and `d' are extra keyword arguments because
they expander would inspect the bindings of `key1' and `key2' first.

Of course, this will only work if calling procedures with keyword
arguments is recognized at expand time vs. run-time. For anonymous
procedures with keyword arguments, we would therefore have to use a
construct like `keyword-call'.