Am Mo., 21. Okt. 2019 um 10:05 Uhr schrieb Lassi Kortela <xxxxxx@lassi.io>:
>
> >> That comes back to the point I raised initially.  With hygienic keywords, the library writers cooperate
> >> to share the same keywords if they want compatibility.   I don't think it works in reality.
> >> Having test: keywords to specify the predicate would be a natural choice, and we can expect multiple,
> >> independently developed libraries would use it.  Do they need to cooperate _beforehand_ to share
> >> the same library that exports 'test:'?  What if one library already exports 'test:', and
> >> another library writer want to have the same semantics of 'test:' but doesn't want to depend on the
> >> original library?
>
> This worries me as well. Keyword arguments exist because people are not
> good at long-term planning. Sharing keywords from a common library is
> exactly that kind of planning.
>
> Another thing is, people (who are not Scheme experts) will not
> understand why they have to import from library C in order to use
> procedures from libraries A and B. It can be acceptable for advanced
> uses, but for basic stuff, I think it's far too complicated.

No. Libraries A and B would, of course, re-export the keywords as they
should be self-contained. For the end user, it will be enough to
import A or B. Nothing fancy, nothing complicated. Moreover, the
library system will/can warn if incompatible bindings are imported
through different libraries. Finally, typos will be caught, which is
good for the non-experts as well.

This is exactly what we already have in R6RS/R7RS with respect to
keywords appearing in macro uses (e.g. `else' and `=>' or `...').

>
> >> There's one obvious solution: Create a library that effectively exports all possible keywords,
> >> and users of keyword arguments import them.  (It is what (gauche keyword) library in Gauche
> >> does).  But then, where's hygiene?
>
> Yes, that's like the C type system where people just use void* all over
> the place so they can get work done :)

One should make sure that there is a sufficiently high entry barrier
to a programming language so that people like these wouldn't even
start programming. :)

>
> It's good to keep in mind that keyword arguments are basically a more
> convenient version of passing in a record. If users have to think about
> stuff like exporting identifiers every time they add a keyword argument,
> that's going to be too complicated IMHO.

I wouldn't say so. Keywords are part of the public interface and
having it documented by adding some exports is good, not bad.

>
> >> That's why I'm claiming keyword arguments isn't much about identifiers but just an extension
> >> of ordinary arguments.  For positional parameters, the semantics of the first parameter differs
> >> completely among procedures, but we don't think it's conflating the protocol.  It is ok that the first
> >> argument of procedure f and the first argument of procedure g has completely different meanings,
> >> and it's callers responsibility to pass appropriate one.  If g takes a procedure that takes filename
> >> as the first argument, then it's caller's responsibility to pass such procedure to g.
> >> The same applies to keyword argument.  If g takes a procedure that takes logger: argument of
> >> a specific type of object, then it's caller's responsibility to pass such procedure.
> >>
> >
> > Keyword arguments could/would make it possible to treat some procedure
> > arguments in a uniform way.
>
> Just realized that this may be useless without allow-other-keys.
>
> If you define a procedure that can use all of its keyword arguments in a
> meaningful way, then the names of those keywords shouldn't be a problem:
> you know the full set of keywords when writing the procedure definition.
>
> Hygienic keywords are useful when a keyword procedure is a wrapper for
> another keyword procedure. For example, a logging wrapper that only
> interprets the logging keywords, and passes all other keywords to the
> procedure that is being logged without interpreting those keywords.
>
> In that case it could be nice if the logging keyword is guaranteed
> unique so it doesn't override some other logging keyword that the
> wrapped procedure may be using.
>
> But even in that case, it will be confusing to the users who have to
> juggle two logging keywords. I don't see any way to do it that won't
> cause confusion to some people at some point in the chain.

This is how Scheme has worked so far. For example, SRFI 1 exports a
procedure `find'. Some other, totally unrelated procedure exported
from another library, may also be called find. For sure, one of the
identifiers has to be renamed if a third part of the program at some
points needs both `find' procedures.

If one cannot wrap one's head around this, one should solely program
in C where header files have to be mutually disjoint.

Scheme already has a certain level of elegance, complexity,
simplicity, orthogonality (or whatever you want to call its essence
:)), so my basic argument is that keyword arguments should work as the
rest of Scheme does.

Anyway, as long as we allow both — hygienic identifiers and
non-hygienic SRFI 88 keyword objects, we get the best of both worlds.
This way, both your and my arguments will have found a solution.

Marc

>
> Maybe parameter objects are a better mechanism for all the hygienic
> stuff. The logging wrapper can bind the logging parameter in the right
> library instead of adding a hygienic logging keyword. People are already
> used to binding parameters to variables that follow ordinary scoping and
> importing rules, so the details have already been explored and are
> understood.

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