Rest arguments
Marc Nieper-Wißkirchen
(03 Mar 2020 08:12 UTC)
|
Re: Rest arguments Lassi Kortela (03 Mar 2020 12:52 UTC)
|
Re: Rest arguments
John Cowan
(03 Mar 2020 14:17 UTC)
|
Re: Rest arguments
Marc Nieper-Wißkirchen
(03 Mar 2020 14:38 UTC)
|
Re: Rest arguments
Lassi Kortela
(03 Mar 2020 15:52 UTC)
|
Re: Rest arguments
Marc Nieper-Wißkirchen
(03 Mar 2020 15:58 UTC)
|
Re: Rest arguments
Lassi Kortela
(03 Mar 2020 16:20 UTC)
|
> In the section "Emulating keywords in Schemes that don't have them", it > is said that the interplay with optional and rest arguments is "somewhat > confusing". Can you explain what you mean by this? In Common Lisp things like this are confusing: (proc a b c :foo 1 :bar 2) :foo and :bar refer to keyword arguments only if the definition of proc expects keyword args at those positions. It's possible to write code that accidentally passes a keyword object as an positional argument. I can't even remember how the keyword and rest parameters work together, and that's the point - when you have trouble remembering the semantics after a year, they may be too complex. Possibly the rest and keyword args used the same part of the list? Who knows. I could look it up, but in a couple of months I'd forget it again. I appreciate a language that sticks to memory and encourages me to write simple code. In Kawa and Racket, I think unquoted keywords are scouted from the argument list before passing the rest of the list to the positional argument parser, but again I don't remember the details, and again the point is that I shouldn't have to remember them. IMHO they don't add enough value to justify the intricate semantics. In general, it's a good benchmark for an over-engineered language feature if you look keep forgetting how to use it, and have to look it up every few months. CL's loop and format are universally like this, as is much of CLOS. > There are good use cases for keyword arguments together with a rest > argument. I am not talking about rest arguments that are used to emulate > optional arguments (as in "assoc" of R7RS-small), but rest arguments > that can consist of an arbitrary number of arguments. > > For example, if we have an addition procedure `plus' in some numeric > library, we want to be able to specify the exact addition algorithm used > through a keyword argument: > > (plus algorithm: naive 1 2 3 4 5 6) I agree that it's useful to have procedures that take both optional parameters (whether using keywords or not), as well as a variable number of positional arguments. However, I don't agree that mixing keywords and rest args in the language's procedure call syntax is a good way to accomplish that goal because it adds ambiguity and complexity to the language. I agree with the benefits you state, but I think the costs outweigh them. One of the main reasons I now prefer Scheme and ML to Common Lisp and Haskell, is that Scheme and ML are sensitive to the total complexity of the language. Many features are reasonable in isolation, but when you add them all up, the total complexity is too much. A sophisticated keyword system is not intrinsically a problem - but if you also have a sophisticated exception system, macro system(s), object system and scoping rules, the total language is so big that it probably no longer promotes better software engineering. I used to be a fan of big languages for many, many years. Only recently came to appreciate from experience that less is more. > As the argument about rest arguments is in the "Emulating ..." section > of the SRFI, it seems to me that the restriction has been made more out > of technical reasons because the rest argument is re-used for keyword > arguments in the portable implementation. > > I don't think that this restriction is needed: > > We can use a parameter object to pass down keyword arguments to a > procedure accepting keyword arguments. Parameters are Scheme's mechanism > to implicitly pass down arguments. > > In other words, every call with keyword arguments is wrapped into a > parameterize form setting the invisible keyword parameter. The body of a > procedure taking keyword arguments is again wrapped into a parameterize > form clearing the keyword parameter. You're right - that is a possible implementation strategy. But is parameterize universal? Bigloo doesn't seem to have it.