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 reduced Marc Nieper-Wißkirchen 21 Oct 2019 11:46 UTC

Am Mo., 21. Okt. 2019 um 09:53 Uhr schrieb Shiro Kawai <xxxxxx@gmail.com>:
>
> On Sun, Oct 20, 2019 at 8:50 PM Marc Nieper-Wißkirchen <xxxxxx@nieper-wisskirchen.de> wrote:
>>
>>
>> If, say, `f', `f1', `f2', and `g' all intend to implement the same
>> `test:' protocol, then it makes sense for their respective libraries
>> to import the same `test:' identifier from a common library. Passing
>> down any value through such a `test:' argument by, say, `g', makes
>> only sense if the callee understands this particular type of value. In
>> other words, they have to cooperate beforehand anyway.
>>
>
> They should in the ideal world, but I'm highly skeptical that it will work in practice.
>
> Because when one start writing library for 'f1', he can't foresee which keyword arguments
> would be shared with future libraries, nor is able to know if there's someone developing
> independent library that uses the same keyword with the same purpose.  The same applies
> to 'f2'.  And they may not care each other's library---their interest isn't there.
>
> It's only the user who cares compatibility of f1 and f2.  Would the user ask the author
> of f1 and f2 to change their code to import the same binding?  But which library should
> they import from?  You don't want to introduce extra dependency, which means extra burden
> of mentenance, just to make a particular user happy.
>
> Or, suppose there's a huge library that provides 'f1' and keyword bindings.
> You write an independent library 'f2', but knows the meaning of 'f1's keyword argument and
> want to implement the same protocol.  But you don't want to depend on the entire 'f1' library
> just to share one keyword binding.  Would you ask the author of 'f1' to split their keyword bindings
> to a separate library?  It's not only just an extra libary, but they should also split the distribution
> package for them, since if a dependency tool tries to fetch the (f1 keyword) library you
> don't want it to pull entire f1 library.
>
> And then, the maintainer of f1 library decided to create an entire new version and changed
> the keyword name, and decided to drop support of old version.  You, on the other hand, need to
> want to keep old keyword name for your users.  You and the f1 author should coopetate
> and move the binding of original keyword from (f1 keyword) package to your f2 package.
>
> Oh wait, there's another f3 package that also depended on (f1 keyword) package, and they
> want to do the same!  Now you have to talk to f3 package author, to create a new common
> library to be used by f2 and f3 libarries.
>
> Nowadays, your software can depend on tens or even more than hundred of libraries, all of
> them evolves mostly independently.  I don't think it is feasible to create a common library
> for common meaning of each keywords.
>
> One can argue that, if you want to share interface, you should import from the same libary---
> but when people talk about such interface, it is a whole interface---procedure signature or
> common slots.  Each keyword is just a piece of it.  However, using hygiene to solve
> the problem, you have to keep your eye on every pieces, not on the interface as a whole.
> That makes the mentenance far more difficult.

While I understand your points that it is hard to develop a stable
interface independently, I don't see how this is an argument against
the possibility of hygienic keywords: With only non-hygienic keywords,
it just gets harder and one has no chance to rename identifiers when
libraries step on each other's toes.

On the other hand, if `f1'. `f2', and `f3' are developed by the same
authors, hygiene will be useful. Or, a library, say `f0', exporting
the keyword and on which `f1', `f2', and `f3' are based, can come from
a future SRFI.

But let me try to give a better example than the `test:' example.
Consider a version of `map' that takes a keyword argument `reverse:'.
When true, the resulting list will be reversed. Furthermore, `map'
shall take optional keyword arguments that are opaque to `map' and
passed down to the procedure called by `map'.

For example:

(map f ls reverse: #t foo: 42)

Here, `f' shall be called with the list item and the keyword argument
`foo:' bound to `42'. However, how can `map' whether to pass down a
keyword argument `reverse:' to `foo:' or whether to change its own
behavior?

If at least `reverse:' is hygienic, the problem is far less urgent.

-- Marc

>
>
>
>
>>
>> What hygiene allows is to have two different, independently created
>> test protocols in the same program. This won't be possible if `test:'
>> is a mere identifier.
>>
>> Anyway, I have also proposed on this list to allow other types than
>> identifiers as markers for keyword arguments. Only when you want
>> hygiene, you would use an identifier. Otherwise, you would use, say, a
>> keyword object as in SRFI 88. Macro writers can do the same.
>>
>> >
>> > 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. For position arguments, this is only
>> possible when we do whole-program transformations (see my CPS example
>> from somewhere above).
>>
>> Marc