Front page | perl.perl5.porters |
Postings from January 2022
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:
foo(%params)
But a new syntax, maybe something like this, could make it instead bind to named
parameters:
foo(:%params)
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
arguments.
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