Am So., 3. Nov. 2019 um 12:18 Uhr schrieb Lassi Kortela <xxxxxx@lassi.io>:
>
> > 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.
>
> I still don't understand why the lambda/kw and call/kw syntax needs to
> be set in stone. As far as I can tell, it does not have to be.
>
> A keyword procedure is often defined in a different place than where it
> is called. That means the definition and the call can use completely
> different syntax, as long as those syntaxes have compatible semantics.

I see your point.

>
> The current 177 call/kw can call Gambit/Gauche/Kawa built-in procedures
> that have been defined using the native keyword syntax of those Schemes.
> It works just fine. This is what I want to preserve :)
>
> > 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.
>
> That's true. However, we probably can't keep that aspect with 177
> without using something IMHO worse like keywords-as-strings or quoted
> symbols.

Options 1, 3, and 4 don't use keywords-as-strings or quoted symbols.

>
> Again, my defense is that 177 does not need to be the only keyword
> syntax, and doesn't need to be the syntax that goes into R7RS-large.
>
> > 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.
>
> The trouble is that implementations don't always conform to the portable
> syntax in the obvious manner. As a practical example, the #u8 vs #vu8
> vector syntax causes trouble. If you write libraries and you care mainly
> about the widest compatibility, with the standards being only a means to
> that end, it's no problem to stick to a least-common-denominator subset
> of all desired syntaxes in your code. It's usually a small sacrifice to
> make if you can achieve more portable code.

True!

But non-conformance of some implementations shouldn't dictate that
things become non-uniform for conformant implementations.

>
> Again, R7RS-large is a big enough effort that maybe it should "bless" a
> particular keyword syntax. I'll leave that decision to others.
>
> > 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.
>
> As a library writer, I would just use whatever mode works :)

I am a mathematician. Beauty matters as much as practicalness. :)

>
> It might be worth writing a "keyword syntax truce" SRFI that makes all
> implementations support the same read syntax for keywords. But it would
> take years until most implementations support that SRFI.

Do you think so? And even if, R7RS-large itself would still take much
longer until completion.

>
> > 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.
>
> For better or worse, the semantics have been dictacted by Common Lisp,
> DSSSL, and 10 Scheme implementations long before work started on
> R7RS-large and 177. Implementations like Gambit and Gauche that use
> kwargs a lot in their built-in procedures will have a hard time if
> incompatible semantics are introduced in a future Scheme standard, not
> to mention the culture shock of programmers coming from any other
> language :)
>
> 177 has never introduced any new semantics, and I don't think it should.
> What it can do, is leave the door open for future standards to have
> semantics that are a compatible superset of what it can do.
>
> > 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.
>
> I agree that this is fine. A fully portable implementation is not
> possible anyway if we want to be compatible with existing native
> keywords. The current R5RS syntax-rules thing is just a fallback so
> every Scheme at least has something.
>
> > 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).
>
> That applies to code written specifically for those Schemes. But I hope
> we'll have an increasing amount of portable code that is not written
> specifically for any particular Scheme implementation. In that
> situation, one has to watch out for things like the :key or key:
> differences anyway.
>
> I regret that 177 probably has to be done in such a way that
> vertical-bars don't protect you from the ambiguity, but the alternatives
> are worse.