Mailing List Archive

I like this idea in theory, it’s come up several times now.

I'm a little unclear how doing this at the core subroutine level is
different/better than just doing it with a hash:

|sub color($x) { my $red = $x->{red} // 0; my $green = $x->{green} // 0;
my $blue = $x->{blue} // 0; ... } |

That syntax has worked forever. If it’s in core we could enforce
defaults and types easier I suppose, but I don’t know if that’s a big
enough benefit.

- scottchiefbaker

On 1/18/24 14:49, Paul "LeoNerd" Evans wrote:

> Something I've written about a few times in various "what might come
> next in Perl" talks, has been adding some kind of named parameter
> support to subroutine signatures.
>
> I now have an implementation as part of XS::Parse::Sublike, that I've
> been using in a few places and seems to be fine:
>
> https://metacpan.org/pod/Sublike::Extended#Named-parameters
>
> How would folks feel about me writing this up into a real PPC document,
> ideally with the aim of trying to get something in place in time for
> 5.40?
>
?

On Thu, 18 Jan 2024 15:03:10 -0800
Scott Baker <scott@perturb.org> wrote:

> I'm a little unclear how doing this at the core subroutine level is
> different/better than just doing it with a hash:

I think much the same reason as signatures in general - it's the sort
of code you write lots and lots of, and it'd be nice if core provided
better support for the boring repetative parts of it.

However - that said, I also found I wanted to use parts of the same
idea in Object::Pad's `ADJUST` blocks for being able to name additional
construction-time parameters, so it may be that we'll want to reuse the
syntax in core's class feature ADJUST blocks as well.

--
Paul "LeoNerd" Evans

leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/

On Thu, 18 Jan 2024 22:49:55 +0000
"Paul \"LeoNerd\" Evans" <leonerd@leonerd.org.uk> wrote:

> Something I've written about a few times in various "what might come
> next in Perl" talks, has been adding some kind of named parameter
> support to subroutine signatures.
>
> I now have an implementation as part of XS::Parse::Sublike, that I've
> been using in a few places and seems to be fine:
>
> https://metacpan.org/pod/Sublike::Extended#Named-parameters
>
> How would folks feel about me writing this up into a real PPC document,
> ideally with the aim of trying to get something in place in time for
> 5.40?

Just for the record, an extensive discussion about this from 2019:
https://www.nntp.perl.org/group/perl.perl5.porters/2019/11/msg256677.html

Also some examples of prior-art from CPAN, in alphabetical order:

https://metacpan.org/pod/Dios

https://metacpan.org/pod/Function::Parameters

https://metacpan.org/pod/Kavorka

https://metacpan.org/pod/Method::Signatures

https://metacpan.org/pod/MooseX::Method::Signatures

On 18.01.24 23:49, Paul "LeoNerd" Evans wrote:
> How would folks feel about me writing this up into a real PPC document,
> ideally with the aim of trying to get something in place in time for
> 5.40?

I'd love it.

On Thu, 18 Jan 2024 at 23:50, Paul "LeoNerd" Evans <leonerd@leonerd.org.uk>
wrote:

> Something I've written about a few times in various "what might come
> next in Perl" talks, has been adding some kind of named parameter
> support to subroutine signatures.
>
> I now have an implementation as part of XS::Parse::Sublike, that I've
> been using in a few places and seems to be fine:
>
> https://metacpan.org/pod/Sublike::Extended#Named-parameters
>
> How would folks feel about me writing this up into a real PPC document,
> ideally with the aim of trying to get something in place in time for
> 5.40?
>
>
Seems to me this is raku style extensions suppressing context of user (from
code base maintenance point of view - bad idea)

How named arguments are implemented in other languages:
https://github.com/happy-barney/perl-wish-list/blob/master/named-arguments/spec/named-arguments-in-other-languages.md

WIP on changes to calling syntax allowing mixing positional and named
arguments as well as multiple list arguments
https://github.com/happy-barney/perl-wish-list/blob/master/named-arguments/spec/named-arguments.md

Shortly:
- there will be no difference in signature declaration
- there will be change in calling syntax and binding

Example (extreme):
sub foo ($a, $b, @a, @b) ..

@b = (10..20);
foo (
:= $b => 1
2,
:= @b
3, 4, 5
);

effective binding:
- $a == 2
- $b == 1
- @b == (10..20)
- @a == 3,4,5

plus bonus:
it will be nice to have %_ to access arguments by name (eg to differentiate
when optional argument was not provided and when provided with 'undef'
value)
- $_{'$a'} == 2
- $_{'@a'} == \ @a (as populated)




> --
> Paul "LeoNerd" Evans
>
> leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS
> http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/
>

I highly prefer Paul's suggestion for a few reasons

1. If you always allow any param to be called by name, you've created a
huge maintenance burden on the library - now everything is a contract
(unless there's magic syntax for private non-nameable Params, which doesn't
sound good)

2. This syntax can easily double for hash destructuring and callsite
shorthand and make sense logically too, whereas the callsite only syntax
would not

On Fri, Jan 19, 2024, 07:26 Branislav Zahradník <happy.barney@gmail.com>
wrote:

>
>
> On Thu, 18 Jan 2024 at 23:50, Paul "LeoNerd" Evans <leonerd@leonerd.org.uk>
> wrote:
>
>> Something I've written about a few times in various "what might come
>> next in Perl" talks, has been adding some kind of named parameter
>> support to subroutine signatures.
>>
>> I now have an implementation as part of XS::Parse::Sublike, that I've
>> been using in a few places and seems to be fine:
>>
>> https://metacpan.org/pod/Sublike::Extended#Named-parameters
>>
>> How would folks feel about me writing this up into a real PPC document,
>> ideally with the aim of trying to get something in place in time for
>> 5.40?
>>
>>
> Seems to me this is raku style extensions suppressing context of user
> (from code base maintenance point of view - bad idea)
>
> How named arguments are implemented in other languages:
>
> https://github.com/happy-barney/perl-wish-list/blob/master/named-arguments/spec/named-arguments-in-other-languages.md
>
> WIP on changes to calling syntax allowing mixing positional and named
> arguments as well as multiple list arguments
>
> https://github.com/happy-barney/perl-wish-list/blob/master/named-arguments/spec/named-arguments.md
>
> Shortly:
> - there will be no difference in signature declaration
> - there will be change in calling syntax and binding
>
> Example (extreme):
> sub foo ($a, $b, @a, @b) ..
>
> @b = (10..20);
> foo (
> := $b => 1
> 2,
> := @b
> 3, 4, 5
> );
>
> effective binding:
> - $a == 2
> - $b == 1
> - @b == (10..20)
> - @a == 3,4,5
>
> plus bonus:
> it will be nice to have %_ to access arguments by name (eg to
> differentiate when optional argument was not provided and when provided
> with 'undef' value)
> - $_{'$a'} == 2
> - $_{'@a'} == \ @a (as populated)
>
>
>
>
>> --
>> Paul "LeoNerd" Evans
>>
>> leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS
>> http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/
>>
>

Op 19-01-2024 om 00:03 schreef Scott Baker:
>
> I like this idea in theory, it’s come up several times now.
>
> I'm a little unclear how doing this at the core subroutine level is
> different/better than just doing it with a hash:
>
> |sub color($x) { my $red = $x->{red} // 0; my $green = $x->{green} //
> 0; my $blue = $x->{blue} // 0; ... } |
>
> That syntax has worked forever. If it’s in core we could enforce
> defaults and types easier I suppose, but I don’t know if that’s a big
> enough benefit.
>
>

It does, and it works, but it gets very tedious.


|sub color($x) { my $red = delete $x->{red} // die "Missing red value";
my $green = delete $x->{green} // die "Missing green value"; my $blue =
delete $x->{blue} // die "Missing blue value"; if ($x->%*) { die
"Unknown parameters ...."; } ... }|

As opposed to simply

|sub color(:$red, :$green, :$blue) { ... }|

I know what I prefer.

HTH,
M4

On Fri, 19 Jan 2024 at 08:09, Veesh Goldman <rabbiveesh@gmail.com> wrote:

> I highly prefer Paul's suggestion for a few reasons
>
> 1. If you always allow any param to be called by name, you've created a
> huge maintenance burden on the library - now everything is a contract
> (unless there's magic syntax for private non-nameable Params, which doesn't
> sound good)
>

My opinion says otherwise, having this syntax will simplify maintenance.
Of course, if you decide to rename parameter ... but that's different story.

I'd suggest you to take a look at C# / Kotlin behaviour of named arguments
- parameters are always positional
- user can choose named argument syntax for better readability

Usage of sigil in binding simplifies reading as well as (with proposed
syntax) allows passing multiple list arguments.
For example, allows do distinguish expected cardinality by declaration and
not by guessing, or smarter wantarray-like behaviour.

sub foo (optional $id, optional @id@).

my $scalar = foo (:= $id => [ 1 ]);
my @list = foo (:= @id => ( [ 1 ], [ 2 ] ));

If you want to discuss let's do it in separate thread with examples


From user's point of view, it's up to caller to decide what is important
(if anything) and what is not so much.
In business logic you often have functions with multiple possible keys or
all optional.

Also there are also different possibilities to extends signatures using
similar syntax (I already posted it some time ago), for example:
- mutually exclusive parameters:

sub connect (
$username := required => ! $token := requires => ! $token,
$password := optional := requires => ! $token && $login,
$token := required => ! $login := requires => ! $login,
)

required / requires takes expression using other parameter names and
evaluates them as as "is provided" / "is not provided"


> 2. This syntax can easily double for hash destructuring and callsite
> shorthand and make sense logically too, whereas the callsite only syntax
> would not
>
> On Fri, Jan 19, 2024, 07:26 Branislav Zahradník <happy.barney@gmail.com>
> wrote:
>
>>
>>
>> On Thu, 18 Jan 2024 at 23:50, Paul "LeoNerd" Evans <
>> leonerd@leonerd.org.uk> wrote:
>>
>>> Something I've written about a few times in various "what might come
>>> next in Perl" talks, has been adding some kind of named parameter
>>> support to subroutine signatures.
>>>
>>> I now have an implementation as part of XS::Parse::Sublike, that I've
>>> been using in a few places and seems to be fine:
>>>
>>> https://metacpan.org/pod/Sublike::Extended#Named-parameters
>>>
>>> How would folks feel about me writing this up into a real PPC document,
>>> ideally with the aim of trying to get something in place in time for
>>> 5.40?
>>>
>>>
>> Seems to me this is raku style extensions suppressing context of user
>> (from code base maintenance point of view - bad idea)
>>
>> How named arguments are implemented in other languages:
>>
>> https://github.com/happy-barney/perl-wish-list/blob/master/named-arguments/spec/named-arguments-in-other-languages.md
>>
>> WIP on changes to calling syntax allowing mixing positional and named
>> arguments as well as multiple list arguments
>>
>> https://github.com/happy-barney/perl-wish-list/blob/master/named-arguments/spec/named-arguments.md
>>
>> Shortly:
>> - there will be no difference in signature declaration
>> - there will be change in calling syntax and binding
>>
>> Example (extreme):
>> sub foo ($a, $b, @a, @b) ..
>>
>> @b = (10..20);
>> foo (
>> := $b => 1
>> 2,
>> := @b
>> 3, 4, 5
>> );
>>
>> effective binding:
>> - $a == 2
>> - $b == 1
>> - @b == (10..20)
>> - @a == 3,4,5
>>
>> plus bonus:
>> it will be nice to have %_ to access arguments by name (eg to
>> differentiate when optional argument was not provided and when provided
>> with 'undef' value)
>> - $_{'$a'} == 2
>> - $_{'@a'} == \ @a (as populated)
>>
>>
>>
>>
>>> --
>>> Paul "LeoNerd" Evans
>>>
>>> leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS
>>> http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/
>>>
>>