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;
[download]

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;
[download]

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

• 0m0.923s plain (with no checks)
• 0m3.688s with my version (with fixes from above)
• 4m4.759s with Attribute::Handlers and Tie::Scalar

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
  ...
}
[download]

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):

• iterators as first class citizens
• inside-out hashes and arrays (think Hash::Util::FieldHash as default implementation, connecting slots would require a keyword)
• more contexts than void, scalar, list
• return constraints inside a subroutine (think Uint sub fib ($nth : Uint) where returning anything but an Uint is an error)
• user defined parser extensions (rewrite from bison/yacc to perl)
• ...

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.