Front page | perl.perl5.porters |
Postings from December 2019
Re: Named Parameters
From:
Dave Mitchell
Date:
December 16, 2019 12:09
Subject:
Re: Named Parameters
Message ID:
20191216120839.GC3620@iabyn.com
On Mon, Dec 02, 2019 at 01:44:54PM +0000, Zefram via perl5-porters wrote:
> Dave Mitchell wrote:
> > :$name1, # named parameter, consumes ("name1", value) arg pair
>
> I'm dubious about this being something that the core should do. Named
> parameters are not a feature of Perl 5 sub calling per se, the way they
> are built into Perl 6. Seems like something that a plugin on CPAN should
> do (once there's a signature plugin mechanism). I worry about a repeat
> of the smartmatch debacle, where the Perl 5 core inhaled too big a dose
> of a specific person's rough translation of a bunch of Perl 6 semantics.
> Especially with the new semantics being available only in this one way
> through this quite specific feature, rather than being a new paradigm
> that shows up in several places.
I really find that whole paragraph astonishing, in that your and my
mental models of the world are so incompatible that I just cannot
understand where you're coming from.
Passing key-value pairs as part of an argument list in perl function calls
is well-established and uncontroversial. It's just that until now there's
been no convenient callee-side mechanism to extract out those args,
together with error checking for mandatory args etc.
The mechanism I've proposed is simple, efficient, and matches the route
used in perl6 plus several of the popular CPAN signature modules.
I really cannot think of a single good reason not to allow it. The usual
argument for doing in CPAN first has been satisfied - ity *had*been done
on CPAN first, and people seem happy with it.
> If it is implemented (especially if in the core), then I'd want there to
> be some way to separate the naming of the parameter in the argument list
> (part of the sub's API) from the naming of the lexical variable (part
> of the sub's implementation). You didn't mention any such mechanism.
I cannot think of a single good reason (apart from pedantry) why the two
need to be separate. It just complicates things.
> However, I also have a concern about copying the Perl 6 ":$name" syntax.
> It's not a priori bad syntax in the Perl 5 context, but you're certainly
> not getting the benefits that that syntax has in the Perl 6 context.
> In Perl 6, in an ordinary expression context ":$name" is shorthand for
> "name => $name", and the syntax for a named argument with API name
> different from internal name likewise resembles a pair-construction
> syntax. In the Perl 5 context, it's tempting to imitate pair syntax
> afresh, getting "apiname => $internalname" and "apiname => $" for
> the names-differing cases, but then we have no Perl 5 syntax for
> the shorthand pair constructor. Perhaps the signature syntax for the
> names-matching case should be "=> $name", although that can never become
> the corresponding pair-constructing shorthand in expression context.
I think :$x is perfectly fine for p5 use.
> I'm also dubious about the way "\" and ":" interact. You show
> "\:@coordinates". I think the naming indicator, whether ":" or "=>",
> should go before the "\". "foo => \@foo" would accurately imitate a
> potential call site, so seems less confusing than anything with the
> "\" first.
On the other hand, I think the naming indicator should be the thing
closest to the name, and thing saying how arguments should be processed
and bound to the name should be more distant.
--
Diplomacy is telling someone to go to hell in such a way that they'll
look forward to the trip