Keywords reduced
Lassi Kortela
(18 Oct 2019 15:25 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:26 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:38 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:39 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:08 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:56 UTC)
|
Re: Keywords reduced
Marc Nieper-Wißkirchen
(23 Oct 2019 07:19 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:48 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:52 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:23 UTC)
|
Re: Keywords reduced
Shiro Kawai
(20 Oct 2019 10:42 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:06 UTC)
|
Re: Keywords reduced
Shiro Kawai
(21 Oct 2019 07:25 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:50 UTC)
|
Re: Keywords reduced
Shiro Kawai
(21 Oct 2019 07:53 UTC)
|
Re: Keywords reduced Marc Nieper-Wißkirchen (21 Oct 2019 11:47 UTC)
|
Re: Keywords reduced
Peter Kourzanov
(21 Oct 2019 15:42 UTC)
|
Re: Keywords reduced
Marc Nieper-Wißkirchen
(21 Oct 2019 15:55 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:23 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