Pretty please: Named arguments

[Russel Winder]

On Sun, 2011-02-27 at 23:03 -0800, Bekenn wrote:
[ . . . ]
> If I remember right, Python has this (optional) feature; I'm not aware 
> of anyone ever complaining about it.  It also nicely provides a solution 
> to the bool argument problem: 
> http://blogs.msdn.com/b/oldnewthing/archive/2006/08/28/728349.aspx
> 
> But wait, there's more!
> 
> Named arguments get a +1 synergy bonus with default arguments.  When 
> using parameter names to specify arguments, the order in which those 
> arguments are passed no longer matters.  Imagine if the Present() method 
> above provided the default argument null for each parameter:

Pythons parameter passing system is fantastic: the combination of
positional parameters, keyword arguments, default values, "rest of
positionals", "rest of keyword arguments" means that handling C and C++
libraries where many functions/methods have many parameters (some of the
graphics libraries have functions with 10s of parameters) far easier
than using C or C++ directly.

It is no surprise to me that the scientific community is taking to the
Python/C/C++ combination in droves.  Python is a great coordination and
top-level UI language leaving the grunt computation to C and C++ -- well
to be honest there is a huge amount of Fortran as well.

It is clear to me that most of the "Big Science" codes need a rewrite,
but it just isn't going to happen, so for all "number crunching" that
doesn't involve brand new codes, interfacing to C, C++ and Fortran is
mandatory.

It should be noted that the Python parameter passing only works as
beautifully as it does because everything in Python is handled with
dictionaries (aka maps). 

[ . . . ]

> 1) Named arguments are not a replacement for positional arguments. 
> Arguments fall into three categories: positional, named positional, and 
> named non-positional.  An argument is positional if no name is supplied. 
>   An argument is named positional if a name is supplied and its position 
> matches the parameter's position in the function declaration.  An 
> argument is named non-positional if a name is supplied and either a) its 
> position does not match the parameter's position in the function 
> declaration, or b) it is immediately preceded by a named non-positional 
> argument.
> 
> 2) No positional argument may appear after a named non-positional argument.
> 
> 3) Named non-positional arguments may appear in any order.

Or just pick up the Python approach in its entirety?

The huge downside of any named parameter approach is that you have data
coupling between the source of the callee and the caller.  This is fine
in a language such as Python where you distribute source and
documentation tools so you can always find out the names of parameters,
this is going to be a bit of a problem in languages where only the
compiled form may be the only distributed form.  Programmers rely on
some other form of documentation other than the source and this leads to
error,

> Potential problems:  The only problems I can foresee here are variations 
> on the situation when there are two (or more) versions of a function 
> with the same number, type, and names of parameters, but in non-matching 
> order, like this:
> 
> void func(int a, char b);
> void func(char b, int a);
> 
> In such a case, the compiler should diagnose an error if named arguments 
> are employed.
> 
> Thoughts?

The Python mechanism relies on the fact that despatch is by name and not
by signature.  Languages that dispatch by signature will have
significantly greater problems! 

-- 
Russel.
=============================================================================
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder at ekiga.net
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel at russel.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20110228/ab810216/attachment-0001.pgp>