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
