That's a perfect example of the sort of things that an expert Perl programmer can understand, but it's not welcoming to newcomers. It also has two serious bugs I see off the top of my head (and that's before parsing precedence, which I can't with that example).

I agree, my bad.

Care to elaborate about the bugs? I see that fib "5\n" would be allowed, so the matching should use \z; then, restrict to ascii via the /a modifier. Precedence is ambiguous (and it shows not to work as intended), so parens are necessary and that should be:

(caller)[3] eq 'fib' or ($nth !~ m{^\d+\z}a or @_) and die $fib_die_ +msg;

Something else?

Of course, this is an acme example only given for showing "it can be done", but such constructs have poor maintainability - which is the entry point of your talk, I guess.

I totally agree with you that good function signatures and an optional, gradual typing system would be great to have, for some style of programming. But looking the other way round, that would weaken a great strength of perl:

Perl is amazingly good at being lousy at typing.</sarcasm>

For the sake of orthogonality, variable type constraints of course would need to be available for every kind of declaration. Currently, the function signature stuff misses that, but it can be done - not with core perl as you say, but with packages belonging to the core, e.g.

use strict; use warnings; use 5.20.0; use Attribute::Handlers; package Uint { require Tie::Scalar; @Uint::ISA = qw(Tie::StdScalar); sub STORE { my ($p,$f,$l) = caller; $_[1] !~ /^\d+\z/a and die "not a positive integer in package $p file $f line + $l, aborted"; ${$_[0]} = $_[1]; }; } sub UNIVERSAL::Uint : ATTR(SCALAR) { tie ${$_[2]}, 'Uint' } sub fib { my $nth : Uint = shift; # check for extra items in @_ missing return $nth if $nth <= 1; return fib( $nth - 1 ) + fib( $nth - 2 ); } say fib @ARGV;

at the cost of lousy performance. On my machine, a fib(30) is

I'm far away and below of the current affairs and state of perl development/improvement, but implementing attribute handling in the core, type constraints via short-circuiting tie for common types (facilitating user-defined types) and allowing attributes for function signature variable attributes in the parser e.g.

sub fib :prototype($) ($nth : Uint) { # check for 1 == @_ already done ... }

probably implementing all that in XS first, would be a huge gain.

There are some things I would wish to have in core proper apart from that and inlining via keywords (and modifiers where sensible):

but then, I should start to explore what is called perl 6, I guess, and many of these things surely have been discussed long ago.

perl -le'print map{pack c,($-++?1:13)+ord}split//,ESEL'

In reply to Re^3: Recap: The Future of Perl 5 by shmem
in thread Recap: The Future of Perl 5 by Ovid

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":



  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.