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)
|
>> 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. >> 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 :) 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. >> 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. 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.