Front page | perl.perl5.porters |
Postings from January 2022
Re: Named argument syntax (was Re: PSC #049 2022-01-07)
Thread Previous
|
Thread Next
From:
Darren Duncan
Date:
January 24, 2022 07:03
Subject:
Re: Named argument syntax (was Re: PSC #049 2022-01-07)
Message ID:
3fcee8a1-cdb8-de9e-e2c6-b1a5cd34d836@darrenduncan.net
On 2022-01-23 12:56 p.m., Juerd Waalboer wrote:
> TL;DR: the case for naming arguments with "=".
>
> Darren Duncan skribis 2022-01-21 21:38 (-0800):
>> But I want to argue that when/if Perl does add native support for named
>> parameters/arguments, which I hope it does, I feel that we must use a NEW
>> syntax to indicate it, and NOT use "=>".
>
> I like the suggestion of leaving "=>" alone (in Raku I find it really annoying
> that it's used both for creating Pairs and for named arguments, which makes
> passing a Pair rather cumbersome), but,
Thank you for the support of my main argument.
>> I propose following an example which is very common in other languages and
>> data formats, and is also better Huffman coded, which is to use the colon ":"
>> to indicate named parameters or arguments.
>
> As someone who uses lots of ternaries, I'm not so sure about this specific
> character. ":" is also involved in decorating sort in another proposal, and is
> already used for attributes and labels. Larry Wall's "first rule of language
> redesign", which asserts that "everyone wants the colon", is very true. Because
> so many people want the colon, it might make sense to pick something else
> whenever feasible.
Well I'm not going to insist on the colon, and your "=" proposal works just as
well for me, and has a lot of precedent.
>> This shouldn't conflict with any other use of the colon that I'm aware of.
>
> Maybe not technically, but visually it's really the same colon as every other
> colon.
>
> As a counter proposal I suggest "=", because it's nicely consistent with
> aesthetics of signatures. If named arguments have no sigil and I don't think
> anyone is currently suggesting giving them any, the distinction between
> assignment to a variable and to a named parameter should be easy enough. If
> computed argument names are required, those could be simply quoted, because
> assignment to a literal string is currently not a thing you can do.
The main problem I see with "=" is that seems to conflict with the fact that
Perl allows assignments to be embedded in the middle of expressions, so how
would a user know that "f($x = $y)" is not an assignment but rather is setting a
named argument.
Actually this raises the very important matter, which is the same issue no
matter what syntax we use to indicate named, in that will Perl support the
argument name coming from an arbitrary expression or variable, or whether only a
hard-coded parameter-name literal is allowed:
my $argname = "x";
f($argname = 42);
f(x = 42);
So are the second 2 lines considered equivalent or is the middle line a
parse/compile error?
I would argue that forbidding the second line can permit some optimizations or
simpler implementations than if the second line was allowed, and I have chosen
to generally forbid it in my MUON/MDL format/language. In particular,
forbidding it means we can be further in the direction of knowing at
parse/compile time whether a particular sub call argument list would be valid
for the sub.
But its a question of what would be considered more Perlish.
> Other languages that use "=" for named arguments include Python, R, Fortran,
> Julia, Kotlin, Maple, and OpenSCAD.
>
> For the common case of f(arg = $arg, foo = $foo, bar = $bar) where the argument
> and variable have the same name, I suggest adding prefix "=": f(=$arg, =$foo,
> =$bar). And, for symmetry, a prefix "=>" for the fat comma equivalent, because
> that would also be useful when populating hashes and using legacy pseudo-named
> arguments.
Yes, and I would argue in favor of the "=$foo" shorthand as well, whether
spelled that or ":$foo" etc, which Raku introduced me to.
-- Darren Duncan
Thread Previous
|
Thread Next