develooper Front page | perl.perl5.porters | Postings from January 2022

Re: Named argument syntax (was Re: PSC #049 2022-01-07)

Thread Previous | Thread Next
Darren Duncan
January 22, 2022 06:37
Re: Named argument syntax (was Re: PSC #049 2022-01-07)
Message ID:
On 2022-01-21 10:03 p.m., Dan Book wrote:
> On Sat, Jan 22, 2022 at 12:39 AM Darren Duncan wrote:
>     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 "=>".
>     So these two things should continue to have the same meaning, and map to 2
>     positional parameters:
>         foo('x', 'y')
>         foo(x => 'y')
>     ... and this would continue to map to a single positional parameter which is a
>     hashref:
>         foo({x => 'y'})
>     Whereas this would map to a named parameter:
>         foo(x: 'y')
> It's certainly an interesting idea and I think similar to something that has 
> been proposed before (not specific to signatures), but for the specific 
> signature feature, consider that one might want to pass a set of named 
> parameters directly from aggregate data sources such as: foo(%params) - it would 
> be a shame to lose this ability as well.

Well I expect there would be syntax made available that would allow us to keep 
doing the valuable features that worked before.

For backwards compatibility, this would continue to bind to positional 
parameters, 2 parameters per hash key-value pair:


But a new syntax, maybe something like this, could make it instead bind to named 


Or see also how Raku handles this.

I didn't say it in my first post, but something I was thinking about how this 
could all be implemented internally...

Internally, the arguments for a sub call are implemented by an ordered 
collection, an array or arrayref or essentially as it is now, with 1 collection 
element per argument, in the same order as the calling code called the sub, but 
each element is now a simple struct which indicates whether it is a positional 
or a named argument, and in the case of named, what parameter name it indicates.

Or we can do something else, but the point is that natively an argument list is 
represented by something which cleanly represents both positional and named 

Optionally or if necessary this struct is represented to user code as some new 
fundamental simple data type, which then lets Perl code have a way to represent 
an argument list as a collection that it can pass around or build or read 
dynamically etc similarly to how can with @_ now given how that's an array, and 
similarly to how Raku has types such as Capture or whatever for representing 
argument lists.

-- Darren Duncan

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About