Email list hosting service & mailing list manager

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)

Re: Rest arguments Lassi Kortela 03 Mar 2020 12:51 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.