develooper Front page | perl.perl5.porters | Postings from November 2019

Jumbo Signatures extensions discussion

Dave Mitchell
November 28, 2019 17:00
Jumbo Signatures extensions discussion
Message ID:
"Your scientists were so preoccupied with whether or not they could,
they didn't stop to think if they should."
    -- Dr Malcolm, Jurassic Park

I want to spend the next year or so adding lots of new features to Perl's
subroutine signatures. Before I start, I need a rough consensus on what
all the new features should look like. Within this thread I will shortly
be creating a number of sub-threads, one for each proposal (with a
suitably altered subject line). To keep things manageable, discussions
about each proposal should occur only within each sub-thread; i.e. don't
discuss things directly within this top-level thread. To discuss something
not covered by the sub-threads, create a new sub-thread with a suitable
new subject line.

The text of each proposal is in a vague pseudo-POD style, but wouldn't
ever pass a POD checker.

I have been slowly developing this set of proposals over the last couple
of years, taking into account: existing CPAN signature modules, Perl 6,
and various p5p discussions (particularly Zefram's ideas). What I have
ended up with is what I hope are (mostly) a coherent set of proposals that
all work with each other syntactically and semantically, and which I am
reasonably confident that I can implement efficiently.  Unless otherwise
stated, each proposal is my (near) last word on the subject, i.e. it's the
way I want things to be done, unless anyone can persuade me otherwise. The
main exception is the proposal on constraints, which I'm not at all
confident about.

I've tried to follow the Perl philosophy of making easy things easy and
hard things possible.

Given the long gestation period, I may have lost/forgotten the original
attributions for various suggestions, so sorry if I haven't credited you.

I intend to allow a month or so for discussions, then start work on
implementing things. I'll concentrate initially on proposals which break
backwards compatibility, with a firm goal of getting all of those into
5.32. Other improvements will come afterwards, and may not all make 5.32.
I'll leave constraints and optimisation till last.

After that plus 2 years, I expect signatures to stop being experimental.

Each proposal is mostly stand-alone, so you can, if you wish, just read
and discuss the ones that interest you (the complete set of proposals is
quite long). However, in terms of referring back to other proposals, they
are designed to be read in roughly the following order. The ones marked X
include potentially non-backwards-compatible suggestions, and so are
probably the ones you should concentrate on initially. You can always come
back in a month or whatever to discuss the others.

    Parameter Attributes
    Named Parameters
    Query Parameters
  X @_ Suppression
    Aliasing and Read-only variables
    Type and Value Constraints and Coercions
    Scope and Ordering
    Miscellaneous suggestions, including
        X Allow a shortcut for a 'default' default value
        X Whitespace
        X Duplicate parameter names should be an error

The "Miscellaneous suggestions" is a bit of a ragtag of random suggestions,
so it would be well worth reading it even you don't have time to read the
whole set of proposals.

Finally, here is a contrived example of a signature which demonstrates
many of the proposals. Some of it will make more sense after each proposal
has been read.

sub foo (
                     # parameter declarations starting with '?' examine,
                     # but don't consume any further arguments:

    ?*@args,         # @args is set to the equivalent of @_ with one
                     # arg shifted; i.e. like a slurpy but peeking ahead
                     # and not actually consuming any args; the '*' means
                     # that each @args element is aliased to a passed arg

    ?$peek_a,        # $peek_a is bound to next arg but without consuming it
    ??$has_a,        # $has_a is set to true if there's an argument for $a
    $a,              # normal scalar parameter
    ?{ print $a },   # embedded code block - runs code; doesn't shift args

    Dog $spot,       # works the same as 'my Dog $spot'
    $b :shared,      # you can use normal variable attributes
    $c :ro,          # at compile time, $c in lvalue context croaks

    \@ary,           # aliases @ary to a passed array reference
    \%hash,          # aliases %hash to a passed hash reference
    *$scalar,        # aliases $scalar to the next argument

                     # Constraints and coercions:
    $d!,             #    croak if $d not defined
    $e isa Foo::Bar, #    croak if $e isn't of that class
    $f is Int
      where $_ > 0,  #    croak if $f not a positive integer

    $x = 0,          # a default value
    $y?,             # short for $y = undef
    \@array?,        # short for \@array = []

    :$name1 = 0,
    :$name2 = 0,     # consume name-value pairs (name1 => ..., name2 => ....)

    @rest           # slurp up any remaining arguments
) { .... }

"You may not work around any technical limitations in the software"
    -- Windows Vista license Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About