def a((b,c,d),e):

[François Pinard]

[George Sakkis]

> Allowing non-default arguments after *varargs doesn't make sense,

In R, one may use the ... format argument anywhere in the argument list,
but may later test if a non-default argument was provided or not.  I
tend to write R a bit like I would write Python, but hopefully, I'll
eventually understand R enough that I could break that habit.

> > keywords may be abbreviated, and much more hairy,

> Hmm.. -1 on this. It may save a few keystrokes, but it's not good for
> readability and maintenability.

That was my first impression too.  Yet, interactively, I found that
feature very convenient.  Already with Python, I use shortcuts
interactively that I would not write nor keep in real, saved, permanent
programs.  And for very common functions and features, which are not
really fluctuating anymore, some abbreviations became well known idioms.

> > the computation of actual expressions given as arguments is lazily
> > postponed until their first use within the function.

> Is this like an implicit lambda before each argument ?

Not exactly true, but that's surely a way of understanding it.  Such
things are not new: I first saw them in Algol-60, except that once an
argument has been evaluated, it is cached and not evaluated again.  It's
true that in R, much more than in Python, evaluation of an argument may
often be computationally expensive.

Moreover, in R, the initial writing of the argument is preserved on
the form of a parsed tree which can be operated upon.  This allow
for strange things (at least for a Python eye), like computing the
symbolic derivative of an argument.  I toyed with this facility to build
mathematical images, and then, animations.  For an exemple, see:

   http://pinard.progiciels-bpi.ca/plaisir/NRart/

and from there, click on `nr.image' near the end.

> If so, why does it have to be restricted to function arguments ? It
> seems to me that argument passing and lazy evaluation are orthogonal
> dimensions.

In R, laziness is automatic while calling functions, but not otherwise,
and from what I saw so far, less meaningful in other contexts anyway.
However, I think laziness is available explicitely if needed (there is
library function that returns a "promise" of its argument).

> Or for a more exotic use:

> def prologLikeSum(a=s-b, b=s-a, s=a+b):
>     return a,b,s
> prologLikeSum(1,2) == prologLikeSum(1,s=3) == prologLikeSum(b=2,s=3) ==
> (1,2,3)

This is exactly how R people use the feature most of the times (at least
so far that I naively saw, as I'm still pretty new at all this).

> This seems pretty hard to change though.

Oh, I would not even dream about it for Python.  The idea would have to
make its way first within the developers, and this might take years, if
ever.  The best I (we) could do is keep the idea in the air, for a good
while.  It would likely never survive all the debates it would generate.
But who knows! :-)

> [...] and even worse, [bindings] would have to be computed for each
> call, as the prologLikeSum example shows.

Yet, already, as it stands, argument passing in Python is not innocuous.
A bit more, a bit less, nobody would notice! :-)

-- 
François Pinard   http://pinard.progiciels-bpi.ca