On 17 Aug 2000, Perl6 RFC Librarian wrote:
> Subroutines: Extend subroutine contexts to include name parameters and lazy arguments
This is great. I've wanted something like this for ages :-)
> The following context modifiers would be available:
>
> \ parameter must be a reference,
> magically en-reference arg if necessary
>
So \@ will allow me to pass in $val (containing a ref to an array) as well
as @vals (which is automatically referenced) - at last! Presumably this
RFC carries with it an run-time as well as compile time component (unlike
the current prototype scheme which is all compile time)? The
implementation section might want to point that out.
Since there is a run-time component we could probably write a
proof-of-concept parser for some of this in perl5 now:
use NamedParameters;
sub mymap {
checkargs("_prototype_ ", @_)
or die "Args did not match description";
}
This could, in perl5, check that the arguments are of the correct type and
number. Not sure how it could create the required lexicals though is
strict 'vars' is turned on (eval would work without strict).
> =head2 Parameter names
> For example:
>
> sub doublemap (&mapsub, @args) { # creates my($mapsub,@args)
> my @mapped;
> push @mapped, $mapsub->(splice @_, 0, 2) while @_;
> return @mapped;
> }
I'm probable missing something but if @args is a named parameter
why is @_ used instead? Are the arguments not removed from
the stack when the lexical variables are created. ie is it
my ($mapsub, @args ) = @_;
or is it:
my $mapsub = shift;
my @args = @_; # arguments are still on stack.
If it's the former then $_[0] is still an alias to the incoming variable.
> An argument would be associated with a named parameter by prefixing it
> with a standard Perl label (i.e. an identifier-colon sequence). For example:
>
> @mapped = doublemap(args: @list, mapsub: ^a+^b);
>
Not sure I like the colon but, as you said in a later post the => is
already in use for exactly this. It would be more perly if named
parameters worked in the style of hashes though:
doublemap( args => @list, mapsub => ^a+^b);
but people may already be using 'args => @list' to pass in scalar(@args).
Named args are effectively hashes anyway :-(
> =head2 Banishment of the term "prototype"
>
> It is further proposed that parameter lists I<never> be referred to
> as "prototypes", and that use of the term be a flameworthy offence.
>
Yes.
Is there any mileage in extending the syntax to allow the
contents of an array or hash to be checked. In general I find quite often
that I am checking to make sure that an array has at least N elements
(ignoring issues with sparseness) and that a hash has a specific set of
keys in it (see eg my PDL::Options module which translates user supplied
keys [generally typed at a command line] into a set of keys the subroutine
actually required [correcting for case and minimum matching]). It seems
only a small jump to go from this RFC to a version that will peek inside
the arguments [but it might be a can of worms].
In summary, I vote for this RFC. :-)
--
Tim Jenness
JCMT software engineer/Support scientist
http://www.jach.hawaii.edu/~timj
