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: Remaining keyword problems Marc Nieper-Wißkirchen 11 Nov 2019 14:56 UTC

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/