> 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;
This would certainly be an interesting and useful module. I
encourage someone to create it. Of course, it couldn't (easily)
include all the named parameter magic, but a partial
proof-of-concept is better than none.
> > sub doublemap (&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?
My screw-up there. Should obviously be:
sub doublemap (&mapsub, @args) {
my @mapped;
push @mapped, $mapsub->(splice @args, 0, 2) while @args;
return @mapped;
}
I'll fix it in the next version of the RFC.
BTW, presumably Perl 6 would have given us a nice:
Parameter @args not used in subroutine doublemap
warning to alert us to the fact :-)
> Are the arguments not removed from
> the stack when the lexical variables are created. ie is it
That's right. @_ always contains aliases to the entire original argument list.
Just as it does in Perl 5.
> 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].
A can of *vipers*, I think! We could push the envelope a *lot* further
out than just peering inside arguments: regexes as type names,
inter-parameteric context constraints, predicate dispatching.
There's such a thing as being *too* powerful.
Besides, this parameter-checking functionality is better handled in
pre- and post-conditions (which I *will* be RFCing RSN -- definitely
by Christmas!) Here's a sneak preview:
# dumb example, but gives a sense of the applications...
# precondition attributes get the sub's argument list and
# must return true, or an exception is triggered
# postcondition attributes get the sub's argument list plus
# it's return value (in $RETURN or @RETURN) and
# must return true, or an exception is triggered
sub delete_many ( \%hash, @keys ) :
pre { @keys > 0 },
pre { exists($hash{$_}) || return for @keys; return "okay" },
post { exists($hash{$_}) && return for @keys; return "okay" },
post { @RETURN == @keys },
{
my @deletes;
push @deletes, delete $hash{$_} for @keys;
return @deletes;
}
Damian
