Am Di., 29. Okt. 2019 um 22:10 Uhr schrieb Lassi Kortela <xxxxxx@lassi.io>:
>
> > - Keywords being global symbols vs hygienic identifiers.

After having thought about it again, I think there is a way out:

We write keywords in the form "foo" or "foo:" (assuming that the
latter is the datum representation of a native keyword). The
implementation of SRFI-177 uses `syntax-rules' to match the keywords,
that is native keywords like "foo:" are matched with "equal?" and
identifiers are matched via "free-identifier=?", that is hygienically.

What does it mean from a practical point of view?

If a consumer of SRFI 177 needs hygienic keywords, no problem.

For all others (probably the majority), just use keywords of the form
"foo:". For Scheme systems supporting SRFI 88, they will be read as
keywords and just matched via "equal?". For Scheme systems, reading
things like "foo:" as identifiers, the matching will be through
"free-identifier=?", which, however, is the same as "equal?" if "foo:"
is not bound! (Which it usually is.)

I think this situation is perfect in the light of that R7RS-large may
include native keywords later. Use the syntax "foo:" already now and
just make a note that identifiers of the form "foo:" mustn't be bound
(which they cannot in systems supporting SRFI 88 anyway).

Marc

> >
> > I will believe in the need for hygienic keywords when someone demonstrates
> > a non-hypothetical use for them.
>
> The idea seems technically sound, but I'm also a bit skeptical that
> well-working social conventions can be established among library writers
> who do not communicate with each other.
>
> Languages like Python, Ruby and Java are better than Scheme at
> programming-in-the-large because as systems grow larger, social factors
> start to dominate technical ones. The typical Lisper doesn't like to
> admit it. I don't like to admit it. But it's true.
>
> As we get out of core abstractions like closures and continuations, and
> towards complexity-management tools like module systems, keyword
> arguments, package management, documentation and tooling, I think we
> should shift focus from mathematical purity to whatever supports
> efficient social customs.
>
> That being said, I don't want to block 177 from interoperating with any
> hygienic keyword system. Fortunately it doesn't have to.
>
> >> - 177 needs to use RnRS-portable read syntax, so we can't use keyword
> >> objects. That means we need to use either symbols or strings to indicate
> >> keyword arguments. Symbols would be the natural way to indicate hygienic
> >> keywords, so it'd be nice to use something else for global keywords.
> >
> > I propose this: if you really must have hygienic keywords, then in systems
> > without keywords, a symbol beginning with ":" is treated as global.
>
> Hmm. Could this be the best of all worlds?
>
> (keyword-call 1 2 3 :foo 4 :bar 5 :baz 6)
>
> This forbids a syntax-rules based implementation. But anyway, the macro
> would scan the list until it finds either:
>
> - A keyword object (in a Scheme that has such objects).
> - A symbol whose name starts with `:`.
> - A symbol whose name ends with `:`.
>
>  From that point on, it would parse keyword-value pairs.
>
> The natural complement for that keyword-call syntax would be John's
> proposed (keyword-lambda (a b c &key foo bar baz) ...).
>
> Opinions?
>
> > If Marc's Chibi library can be made to cover Chicken, Gauche, and MIT
> > (which will need patches for each one), I'd say that making syntax-case a
> > standard is feasible.
>
> Sounds great. I'm not qualified to judge syntax-case vs ER.
>
> > I don't understand that. If a portable R7RS-large library wants to expose
> > procedures that have keywords (and I'd like that), then it has to use
> > either SRFI 177 conventions or some other conventions.
>
> I mean the library writer and the library user can use different keyword
> systems as long as those systems are compatible. For example I've called
> Gambit's native procedures that take keyword arguments using SRFI 177
> keyword-call; it worked fine.
>
> This also implies that either the user or the library writer can switch
> to a different keyword implementation at any time, independently of each
> other, as long as those implementations are compatible.
>
> 177 is lowest-common-denominator so that it's compatible with anything
> else, and so that it can be replaced with anything else. If it's not as
> compatible it will fail; you just inadvertently presented a better
> explanation of such failure than I did :)
>
> > +1.  I have carefully avoided the need for them in R7RS-large so far, but
> > SRFIs and pre-SRFIs are now starting to appear that simply have too many
> > options to be handled as standard Scheme arguments.
>
> That's generally a good indication that a solution is called for.
>
> Another good case: go to the Common Lisp spec and imagine what some of
> the built-in procedures would look like if you take out the keyword
> arguments.

--
Prof. Dr. Marc Nieper-Wißkirchen

Universität Augsburg
Institut für Mathematik
Universitätsstraße 14
86159 Augsburg

Tel: 0821/598-2146
Fax: 0821/598-2090

E-Mail: xxxxxx@math.uni-augsburg.de
Web: www.math.uni-augsburg.de/alg/mitarbeiter/mnieper/