Re: mixed, named notation support

On Sun, Aug 9, 2009 at 12:27 PM, Tom Lane<tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Now that I've started to read this patch ... exactly what is the
> argument for allowing a "mixed" notation (some of the parameters named
> and some not)?  ISTM that just serves to complicate both the patch
> and the user's-eye view, for no real benefit.

Wow, I can't imagine not supporting that. Doesn't every language that
supports anything like named parameters also support a mix? LISP is
the obvious example, but I think most major scripting languages (Perl,
Ruby, etc.) support something akin to this through a trailing hash
argument. C# apparently supports both for something called attribute
classes (don't ask me what they are). Ada also supports both styles,
and you can mix them.

http://msdn.microsoft.com/en-us/library/aa664614(VS.71).aspx
http://goanna.cs.rmit.edu.au/~dale/ada/aln/8_subprograms.html#RTFToC11

The case where this is really useful is when you have lots of
parameters most of which don't need to be set to a non-default value
most of the time, but a few of which always need to be specified. In
C you might do something like this:

int frobozz(int common1, int common2, struct frobozz_options *fopt);
/* fopt == NULL for defaults */
void init_frobozz_options(struct frobozz_options *);

...but the named/mixed syntax is more compact, and certainly nice to
have, even if I'm emphatically not in love with the syntax we're stuck
with.

ISTM that the Ada rule that all positional must proceed all named is a
good one, and to resolve the problem you're talking about here it
seems we should probably also make a rule that specifying a value for
the same parameter more than once (either both position and named, or
named twice) is an error.

It would also be quite reasonable to impose a requirement that
parameters can only be specified using named notation if it has been
explicitly enabled for that particular parameter. In LISP, there are
four kinds of parameters (required, optional, rest, keyword) and any
particular parameter gets to be exactly one of those four things. The
rule for resolving ambiguities may not be what you want, but it's
well-defined and pretty reasonable.

http://gigamonkeys.com/book/functions.html#mixing-different-parameter-types

...Robert