Signature proposal concerns

Front page | perl.perl5.porters | Postings from October 2012

Signature proposal concerns

Thread Next

From:

Dave Rolsky

Date:

October 28, 2012 09:41

Subject:

Signature proposal concerns

Message ID:

alpine.DEB.2.00.1210281122020.9937@urth.org

I have a few concerns about the signature proposal as it stands, primarily 
about how this will play nicely with certain features that might be added 
in the future (either via CPAN or core).

I know Peter Martini has already thought about default values, which is 
great, as this is one important future feature for subroutine signatures.

I do think it's important to make sure that defaults can be dynamic, so we 
can write these:

   sub foo ( $bar = 5 ) {  }
   sub foo ( $foo, $bar = $foo * 2 ) { }

Or even worse:

   sub foo ( $foo, $bar = ( $foo * 2 ) ) { }
   sub foo ( $foo, $bar = sub { ... } ) { }

This just means that the prototype parser code must be open to being smart 
in the future, even if it's not smart right now. By smart I mean basically 
that it has to handle balanced delimiters properly. Right now it can 
simply look for m/\)\s*{/ but that won't be good enough for more complex 
cases.

Another possibility that needs to be left open is named args. Personally, 
I'm really not interested in positional parameter list improvements, 
because positional params aren't very flexible for future API changes. I'd 
like to see the possibility of associating caller names with sub arguments 
in the future, a la Perl 6:

   sub foo ( $foo, $bar ) { }

   foo( foo => 42, bar => 'whatever' );

This might need a little syntax on the caller side too, maybe something 
like "foo = 42" which is currently more or less illegal under strict 
(unless foo() is an lvalue sub?).

One particular case for named args to consider is this:

   sub foo ( $foo, %bar ) { }
   sub foo ( $foo, %bar, $baz ) { }

How does this play out with the use of slurp parameters in positional 
param lists? Maybe this is resolved by having caller syntax that makes it 
clear that this is a named parameter call ("foo = 42, bar = { ... }").

And of course, are subs callable with both named params _or_ positional 
params, or can a sub require just one or the other? Maybe this is just an 
issue of documentation. If I want people to use named params, I only 
document this calling style.

The implementation should also leave the possibility of type annotation 
open:

   sub foo ( Int $foo, Str $bar ) { }
   sub foo ( $foo where { $foo < 42 } ) { }

The exact syntax is obviously debatable, but I think supporting both 
pre-defined (named _and_ anon) types as well as inline type constraints is 
important.

I know some of these issues have come up in the discussion so far, but I 
just wanted to summarize all the issues I could think of.

If the current implementation doesn't block any of these future paths, I 
don't have any strong objection to it. If it _does_ block some of these 
use cases, I don't think it should go in core until this is resolved.


Cheers,

-dave

/*============================================================
http://VegGuide.org               http://blog.urth.org
Your guide to all that's veg      House Absolute(ly Pointless)
============================================================*/

Thread Next