develooper Front page | perl.perl5.porters | Postings from August 2023

Tiny Signatures Extension Discussion

Thread Next
August 19, 2023 14:56
Tiny Signatures Extension Discussion
Message ID:
Back in 2019, Dave Mitchell shared the Jumbo Signatures extension discussion
That thread was amazing. Lots of great ideas.

*Lots* of great ideas means lots of work and makes it harder to get it
accepted. I want to start smaller. Stealing Borrowing some of his ideas,
but simplifying some of them (while allowing room for expansion), and
focusing on "high demand" features. Further, by starting smaller, we have
fewer bugs.

The features I want to focus on are:

   1. Attributes for signatures variables
   2. Named arguments
   3. Aliasing

This is a small list, but focusing on those things that, er, I most want.
By having a smaller discussion, we have a better chance of moving forward,
and if we can get to an accepted PPC, we can give a strong signal to the
Perl community that we're moving forward.
<>Signature Attributes

This is on hold while Paul continues to work on feature-class
<>Named Arguments

For a first pass, named arguments and positional arguments would be
mutually exclusive. This is a limitation that can be lifted in future
versions, if needed. This has the advantage that (as far as I can tell),
it's forward-compatible with Dave's proposal.

sub orders(:$name, :$since //= undef, :@items) { ... }

The above would be sort of equivalent to:

sub orders {
    my %arg_for = @_;
    my $name    = delete $arg_for{name} or die ...;
    my $since   = delete $arg_for{since};
    my @items   = exists $arg_for{items} && 'ARRAY' eq ref $arg_for{items}
        ? delete $arg_for{items}->@*
        : die ...;
    if ( keys %arg_for ) {
        die ...; # unknown keys

Which would you rather write?

It would be called with a flat list:

my $orders = orders( name => $name, since => $date, items => \@items
);# ormy $orders = orders( name => $name, items => \@items );

If we have :$names, of course $arg_for{names} could be an array ref. :@names is
a useful convenience.

This would depend on attributes in signatures.

sub foo( $bar :alias ) { ... }

In the above, regardless of what $bar is, it's an alias to the argument
passed to foo, just as if we used $_[0] instead.

This one could *almost* be left off the list, since references are kinda
already aliases. However, when I'm walking and mutating complex data
structures, I don't want to handle the special case of non-reference versus
reference. I just want to know that I can mutate the calling value directly.

Generally speaking, this is a terrible idea. Practically speaking, it makes
some code much simpler and can be extremely performant.

Given that this is a much smaller set of suggestions, can we commit to
this? This isn't saying we do this now; it would be saying "we plan to do
this." Named arguments and aliases would go a long way towards killing off
@_ (not really removing it, but making it less much less likely to be

Not allowing positional and named arguments to be mixed might be
controversial, but I've found that having something like an "options" or "
extra" key works around that nicely.

This would be, like Corinna, an MMVP (a minimally minimal viable product),
with an eye towards later revisiting Dave's jumbo list. However, it would
send a strong signal to the Perl community that popular needs are being
addressed and Perl is maturing into a modern language.


Curtis "Ovid" Poe
CTO, All Around the World
World-class software development and consulting

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