Am So., 3. Nov. 2019 um 10:56 Uhr schrieb Lassi Kortela <xxxxxx@lassi.io>:
>
> Thanks for sticking with the discussion even though your opinions have
> been in a minority all this time. I'm confident we can find some way to
> do keywords that doesn't preclude hygienic identifiers and doesn't
> mandate parsing magic symbols like :foo and foo:. The 177 macros don't
> need to be the be-all end-all syntax for using keyword args.

As soon as other SRFIs (especially SRFIs for inclusion into
R7RS-large) begin to use SRFI 177 in their external API, things will
be set into stone.

Thus, let's be careful from the beginning.

>
> >>>> (let ((:e 3))
> >>>>    (keyword-call foo 1 2 :e 4))
> >>
> >> The `e` keyword argument would get the value 4.
> >>
> >> 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).
>
> In my view, what matters is the semantics (that lambdas can declare
> keyword arguments, and there is some way to call one and supply them). I
> also find it important that keyword lambdas can be called like ordinary
> lambdas (which allows adding keyword arguments to procedures that did
> not take any before, e.g. the port settings in John's pre-draft).
>
> The kw syntax doesn't matter; Scheme can and will have multiple such
> syntaxes for many years. So if R7RS-large wants to have a completely
> different syntax to define and call keyword lambdas, that's perfectly
> fine with me as long as the semantics are compatible with SRFI 177.
>
> > This would be just a wart in the Scheme language, destroying Scheme's
> > uniformity.
>
> We call that a macro :)

No. :)

While you can certainly define macros that destroy this uniformity,
all special forms (including macros) in R7RS(-large) retain Scheme's
uniformity.

For example, "cond" and "case" match "else" and "=>" hygienically and
do look at how "else" or "=>" are spelled.

Let's keep this uniformity with SRFI 177.

>
> But seriously, you have a good point and I agree. The reason I think
> it's acceptable in this case, is that several Schemes already treat foo:
> and/or :foo as a non-identifier. So if you're reading random Scheme code
> and see :foo or foo: in there, and don't carefully check which
> implementation it was written for, you cannot assume that it is an
> identifier.

In R7RS, both ":foo" and "foo:" are well-defined identifiers. Thus
conformant implementations have to treat ":foo" and "foo:" as
identifiers.

R7RS-large builds upon R7RS.

Of course, one could think of a reader flag "#!keywords" that changes
how ":foo" and/or "foo:" are read. In this case, however, they would
be no identifiers and my argument from above doesn't apply.

In the absence of such a flag, however, ":foo" and "foo:" are
identifiers in portable (R7RS-portable) code.

>
> Hence from my point of view, 1777's call/kw would not really be
> introducing new ambiguity to the language; it would just formalize the
> old ambiguity. That's not ideal, but I think it's better than the
> alternatives where you read foo: or :foo inside a call/kw, and it may or
> may not be a keyword object depending on the implementation.
>
> Put yet another way: 8 Scheme implementors as well as DSSSL have already
> destroyed the uniformity of identifiers; I'm just documenting the job :)

The best way out would be to standardize something like "#!keywords"
first. When this flag is not enabled in a source file, Schemes should
offer an R7RS conformant mode if they claim R7RS conformity.

> > 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.
>
> I agree. In my view, it's more a question of what is an identifier and
> what is not. Currently :foo and foo: are indeed read as identifiers in
> most Scheme implementations, but not in all of them, so their status as
> an identifier is already unclear. Some implementations even have reader
> options that change whether those are read in as identifiers on the fly.

See above.

>
> The call/kw abstraction is leaky, because |:foo| and |foo:| with
> vertical bars are probably read as identifiers even in all Schemes that
> have keyword objects; whereas call/kw would read them as keywords. But
> this is getting into really esoteric corner cases.

Let's first try to get the semantics (and syntax) of SRFI 177 right.
And in a way such that SRFI 177 allows for native implementations by
various Schemes.

If the reference implementation can only implement 98% of the
semantics (because 2% have to implemented non-portably), it's fine as
long as it is not hard for each Scheme to copy with the remaining 2%
individually.

>
> >>>> 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.
>
> It's definitely not too much to demand intelligence- or
> sophistication-wise. But IMHO it reads unnaturally, and it's one of
> those little things that has to be kept in mind. Good design means
> people don't need to think about the details; the intuitive way to do
> things is also the right way.

But good design also includes the uniformity I mentioned above. And
here, it would become non-uniform and non intuitive, especially in
Scheme dialects where the natural keyword syntax is "#:key" (which is
probably better than ":key" or "key:" because it does not clash with
the R7RS identifier syntax).

>
> > 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.
>
> We all agree that would be ideal. 177 just has to do a compatibility
> hack in the meantime.
>
> If R7RS-large gets keyword objects, maybe it can use a version of
> call/kw that only accepts keyword objects and doesn't try to parse
> identifiers. I would not be opposed to that. IMHO R7RS-large can have
> keyword arguments without requiring them to be used with the 177 macros.
>
> >> 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 :.
>
> Nice. For this kind of syntax, I would still prefer (call/kw 1 2 3 (a 4
> b 5 c 6)) however. Since this is Lisp, I think it's more obvious to use
> a list than a delimiter to indicate substructure. Keywords like :foo are
> an exception because they've been around for decades so we've grown used
> to them.