Email list hosting service & mailing list manager

Keywords reduced Lassi Kortela (18 Oct 2019 15:24 UTC)
Re: Keywords reduced John Cowan (18 Oct 2019 20:48 UTC)
Re: Keywords reduced Lassi Kortela (18 Oct 2019 22:24 UTC)
Re: Keywords reduced Marc Nieper-Wißkirchen (19 Oct 2019 08:25 UTC)
Re: Keywords reduced John Cowan (19 Oct 2019 19:04 UTC)
Re: Keywords reduced Marc Nieper-Wißkirchen (20 Oct 2019 09:15 UTC)
Re: Keywords reduced John Cowan (21 Oct 2019 17:26 UTC)
Re: Keywords reduced Marc Nieper-Wißkirchen (21 Oct 2019 18:37 UTC)
Re: Keywords reduced Shiro Kawai (21 Oct 2019 19:27 UTC)
Re: Keywords reduced Marc Nieper-Wißkirchen (22 Oct 2019 06:04 UTC)
Re: Keywords reduced Shiro Kawai (22 Oct 2019 10:07 UTC)
Re: Keywords reduced John Cowan (22 Oct 2019 19:33 UTC)
Re: Keywords reduced John Cowan (22 Oct 2019 19:38 UTC)
Re: Keywords reduced Lassi Kortela (22 Oct 2019 20:06 UTC)
Syntactic keywords vs parentheses Lassi Kortela (22 Oct 2019 20:30 UTC)
Re: Syntactic keywords vs parentheses John Cowan (22 Oct 2019 20:54 UTC)
Re: Syntactic keywords vs parentheses Lassi Kortela (22 Oct 2019 21:07 UTC)
Re: Syntactic keywords vs parentheses Shiro Kawai (22 Oct 2019 22:24 UTC)
Re: Syntactic keywords vs parentheses Lassi Kortela (23 Oct 2019 07:40 UTC)
Re: Syntactic keywords vs parentheses John Cowan (22 Oct 2019 23:12 UTC)
Re: Syntactic keywords vs parentheses Amirouche Boubekki (25 Oct 2019 11:55 UTC)
Re: Keywords reduced Marc Nieper-Wißkirchen (23 Oct 2019 07:18 UTC)
Re: Keywords reduced John Cowan (21 Oct 2019 23:06 UTC)
Re: Keywords reduced Shiro Kawai (22 Oct 2019 00:42 UTC)
Re: Keywords reduced Marc Nieper-Wißkirchen (22 Oct 2019 06:12 UTC)
Re: Keywords reduced Lassi Kortela (22 Oct 2019 10:56 UTC)
Re: Keywords reduced Lassi Kortela (20 Oct 2019 09:42 UTC)
Remaining keyword problems Lassi Kortela (29 Oct 2019 17:59 UTC)
allow-other-keys Lassi Kortela (29 Oct 2019 18:29 UTC)
Re: allow-other-keys John Cowan (29 Oct 2019 18:55 UTC)
Re: allow-other-keys Shiro Kawai (29 Oct 2019 19:18 UTC)
Re: allow-other-keys Lassi Kortela (29 Oct 2019 23:04 UTC)
Re: allow-other-keys Marc Feeley (29 Oct 2019 21:05 UTC)
Re: allow-other-keys Marc Nieper-Wißkirchen (03 Nov 2019 08:16 UTC)
Re: allow-other-keys Lassi Kortela (03 Nov 2019 10:11 UTC)
Re: allow-other-keys Marc Nieper-Wißkirchen (03 Nov 2019 10:34 UTC)
Re: allow-other-keys Lassi Kortela (03 Nov 2019 10:54 UTC)
Re: allow-other-keys Marc Nieper-Wißkirchen (03 Nov 2019 11:13 UTC)
Re: allow-other-keys Lassi Kortela (03 Nov 2019 11:39 UTC)
Re: allow-other-keys Arthur A. Gleckler (03 Nov 2019 18:39 UTC)
Re: allow-other-keys Marc Nieper-Wißkirchen (03 Nov 2019 18:47 UTC)
Re: allow-other-keys John Cowan (03 Nov 2019 19:20 UTC)
Re: allow-other-keys John Cowan (03 Nov 2019 19:18 UTC)
Re: allow-other-keys Marc Nieper-Wißkirchen (03 Nov 2019 19:51 UTC)
Re: allow-other-keys John Cowan (03 Nov 2019 22:19 UTC)
Identifier syntax and the range of Schemes to support Lassi Kortela (03 Nov 2019 19:54 UTC)
Re: Remaining keyword problems John Cowan (29 Oct 2019 19:51 UTC)
Re: Remaining keyword problems Lassi Kortela (29 Oct 2019 21:09 UTC)
Alternative syntax using colon symbols for portable keywords Lassi Kortela (29 Oct 2019 22:29 UTC)
Re: Remaining keyword problems Marc Nieper-Wißkirchen (11 Nov 2019 14:56 UTC)
Re: Remaining keyword problems Lassi Kortela (11 Nov 2019 16:15 UTC)
Re: Remaining keyword problems Marc Nieper-Wißkirchen (11 Nov 2019 14:44 UTC)
Re: Remaining keyword problems John Cowan (11 Nov 2019 16:48 UTC)
Re: Remaining keyword problems Marc Nieper-Wißkirchen (11 Nov 2019 17:06 UTC)
Re: Remaining keyword problems John Cowan (11 Nov 2019 17:15 UTC)
Re: Keywords reduced Shiro Kawai (19 Oct 2019 09:25 UTC)
Re: Keywords reduced Lassi Kortela (19 Oct 2019 09:38 UTC)
Re: Keywords reduced Marc Nieper-Wißkirchen (19 Oct 2019 12:22 UTC)
Re: Keywords reduced Shiro Kawai (19 Oct 2019 18:43 UTC)
Re: Keywords reduced Marc Nieper-Wißkirchen (20 Oct 2019 08:39 UTC)
Re: Keywords reduced Lassi Kortela (20 Oct 2019 09:28 UTC)
Re: Keywords reduced Shiro Kawai (20 Oct 2019 10:12 UTC)
Re: Keywords reduced Shiro Kawai (20 Oct 2019 10:17 UTC)
Re: Keywords reduced Lassi Kortela (20 Oct 2019 10:22 UTC)
Re: Keywords reduced Shiro Kawai (20 Oct 2019 10:41 UTC)
Re: Keywords reduced Marc Nieper-Wißkirchen (20 Oct 2019 21:10 UTC)
Re: Keywords reduced Shiro Kawai (20 Oct 2019 21:19 UTC)
Re: Keywords reduced Marc Nieper-Wißkirchen (20 Oct 2019 21:33 UTC)
Re: Keywords reduced Shiro Kawai (20 Oct 2019 22:05 UTC)
Re: Keywords reduced Marc Nieper-Wißkirchen (21 Oct 2019 07:01 UTC)
Re: Keywords reduced Shiro Kawai (20 Oct 2019 22:18 UTC)
Re: Keywords reduced Marc Nieper-Wißkirchen (21 Oct 2019 07:05 UTC)
Re: Keywords reduced Shiro Kawai (21 Oct 2019 07:24 UTC)
Re: Keywords reduced Marc Nieper-Wißkirchen (20 Oct 2019 21:04 UTC)
Re: Keywords reduced Shiro Kawai (20 Oct 2019 21:41 UTC)
Re: Keywords reduced Marc Nieper-Wißkirchen (21 Oct 2019 06:49 UTC)
Re: Keywords reduced Shiro Kawai (21 Oct 2019 07:52 UTC)
Re: Keywords reduced Marc Nieper-Wißkirchen (21 Oct 2019 11:46 UTC)
Re: Keywords reduced Peter Kourzanov (21 Oct 2019 15:42 UTC)
Re: Keywords reduced Marc Nieper-Wißkirchen (21 Oct 2019 15:54 UTC)
Re: Keywords reduced Shiro Kawai (21 Oct 2019 17:38 UTC)
Re: Keywords reduced John Cowan (21 Oct 2019 17:45 UTC)
Re: Keywords reduced Lassi Kortela (22 Oct 2019 08:21 UTC)
Keywords vs paremeters for hygiene Lassi Kortela (21 Oct 2019 08:05 UTC)
Re: Keywords vs paremeters for hygiene Marc Nieper-Wißkirchen (21 Oct 2019 11:22 UTC)

Re: Keywords vs paremeters for hygiene Marc Nieper-Wißkirchen 21 Oct 2019 11:22 UTC

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/