Re: Hoping that Params::Validate is not needed in Perl6

16 views
Skip to first unread message

Uri Guttman

unread,
Aug 17, 2005, 5:37:11 PM8/17/05
to Dave Rolsky, perl6-l...@perl.org
>>>>> "DR" == Dave Rolsky <aut...@urth.org> writes:

DR> Mandatory vs. Optional Parameters

DR> This is a pretty straightforward one in P6, I think. Parameters can
DR> be marked as required with "is required" like this:

DR> sub date ($year, ?$month, ?$day) # positional

DR> sub date (+$year is required, +$month, +$day) #named

DR> This is ok but frankly I'm not too keen on the fact that for
DR> positional subs, the default is required, but for named params it's
DR> the other way around.

DR> Wouldn't it clearer to just use a leading "?+" for optional named params?

there are usually more optional params than required ones when doing
named params. so that makes sense to make the default optional. with
positional params usually more of them are required (on the left) and
some optional ones can be on the right. so marking those optional ones
makes more sense. this is all huffman stuff IMO.

uri

--
Uri Guttman ------ u...@stemsystems.com -------- http://www.stemsystems.com
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org

Dave Rolsky

unread,
Aug 17, 2005, 5:27:23 PM8/17/05
to perl6-l...@perl.org
One of the things I'm looking forward to in Perl6 is greatly improved
sub/method signatures.

I'm hoping that this will eliminate the need for anything like
Params::Validate, which IMO is a nasty hack to make up for a serious
weakness in Perl5.

I'm going to go over the various features in P::V and see if there are
equivalents in Perl6, and bring up any questions I have. I think this
will be interesting for folks still new to P6 (like myself) and existing
P::V users (I think there's a fair number, but maybe I flatter myself ;)


Mandatory vs. Optional Parameters

This is a pretty straightforward one in P6, I think. Parameters can be

marked as required with "is required" like this:

sub date ($year, ?$month, ?$day) # positional

sub date (+$year is required, +$month, +$day) #named

This is ok but frankly I'm not too keen on the fact that for positional
subs, the default is required, but for named params it's the other way
around.

Wouldn't it clearer to just use a leading "?+" for optional named params?


Default Values

sub date ($year, ?$month = 1, ?$day = 1)

sub date (+$year is required, +$month = 1, +$day = 1)

Again, nice and straightforward.


Type Validation, "isa", & "can"

Params::Validate allows for several ways to check the _value_ of a
parameter. One way is to specify a primitive type like "SCALAR" or
"ARRAYREF". In P6 we have that with this:

sub date (Scalar +$year is required, ...)

I'm not sure is "Scalar" is a valid type though, but that's ok because we
have better types built in. In this case we should really use "Int" for a
year.

P::V also allows one to specify a class membership ("isa)" or one or more
methods ("can") a given object/class must have. In Perl6 we can just
specify a class:

sub transmit (Receiver $receiver)

If I understand this correctly, Receiver is a role here, and one that many
different classes may use/implement. This basically combines the isa &
can concepts. Instead of specifying required _methods_, we specify the
role, which seems conceptually cleaner anyway.


Regexes and Callbacks

P::V lets you validate a value based on a regex or one or more callbacks.
I think these can be replaced with subtypes, which is one of the most
exciting new P6 features (for me).

So instead of this (Perl5 P::V):

{ size => { callbacks =>
{ 'is a valid month' => sub { $_[0] >= 1 && $_[0] <= 12 }

we can now do this:

my subtype Month where { 1 <= $^s <= 12 }

This is so freaking awesome!

Then we just reference the subtype in our sub declaration:

sub date { $year, Month ?$month = 1, Day ?$day = 1 }

Subtypes can also be defined as regexes:

my subtype PerlIdentifier where / <+<alpha>+[_]> <+<alpha>+<digit>+[_]>* /;

(not 100% sure on that rule but you get the idea)


Dependencies, Exclusions, and "Require one-of"

With P::V I can do this:

{ credit_card_number =>
{ optional => 1,
depends => [ 'credit_card_expiration', 'credit_card_holder_name' ] },

credit_card_expiration => { optional => 1 },

credit_card_holder_name => { optional => 1 },
}

I have no idea how I might do this in Perl6, but I would love to see it
supported as part of parameter declarations

Similarly, something I've wanted to add to P::V is exclusions:

{ credit_card_number =>
{ optional => 1,
excludes => [ 'ach_bank_account_number' ] },
}

Another thing that would be really nice would be to require one of a set
of parameters, or one set out of multiple sets, so we could say "we need
credit card info _or_ bank account info".

For example, with the examples above, I probably want to require _either_
a credit card number _or_ a bank account number. Providing both is an
error, but so is not providing either.

Again, no idea how to do this in Perl6, but it seems like something that
could be supported via sub declarations

Since all of these can be checked at compile time (sometimes), it seems
like they'd be useful parts of the language, as opposed to something
user-created. Of course, I understand that there will be more ways to
mess with the compilation in Perl6.


Transformations

Another potential future feature for P::V is the ability to specify some
sort of transformation callback for a parameter. This is handy if you
want to be flexible in what inputs you take, but not explicitly write code
for all cases:

{ color => { regex => qr/^(?:green|blue|red)$/i,
transform => sub { lc $_[0] } }
}

I suspect that this could be implemented by a user-provide trait like "is
transformed":

sub print_error ($color where m:i/^ [green | blue | red] $/ is transformed { lc })

Presumably this can be done with the existing language. It doesn't add
anything at compile time, so it really doesn't need to be part of the
language.

Anyway, I'd love to hear feedback on this. What did I get right? What
did I get wrong? Did I miss a more elegant way to do something? What
other types of param validation do other folks use/want to see?

-dave

/*===================================================
VegGuide.Org www.BookIRead.com
Your guide to all that's veg. My book blog
===================================================*/

Luke Palmer

unread,
Aug 17, 2005, 6:06:07 PM8/17/05
to Dave Rolsky, perl6-l...@perl.org
On 8/17/05, Dave Rolsky <aut...@urth.org> wrote:
> I'm going to go over the various features in P::V and see if there are
> equivalents in Perl6, and bring up any questions I have. I think this
> will be interesting for folks still new to P6 (like myself) and existing
> P::V users (I think there's a fair number, but maybe I flatter myself ;)

Thanks!

> P::V also allows one to specify a class membership ("isa)" or one or more
> methods ("can") a given object/class must have. In Perl6 we can just
> specify a class:
>
> sub transmit (Receiver $receiver)
>
> If I understand this correctly, Receiver is a role here, and one that many
> different classes may use/implement. This basically combines the isa &
> can concepts. Instead of specifying required _methods_, we specify the
> role, which seems conceptually cleaner anyway.

... Sometimes. We are missing the "can" functionality (except from
where clauses). That is, how do you specify that you want an object
that does a particular role, but doesn't know it yet. I'm thinking
something like:

role Mortal is automatic {
method die () {...}
}

That is, anything that can "die" is Mortal, even though it didn't say
that it was. Then what really gets tricky is this:

role Mortal is automatic {
method die () {...}
method jump_off_building() { die }
}

class Human {
method die () { die "Auuugh" }
}

Human.new.jump_off_building; # no method found or "Auuugh"?

Anyway, that's beside the point. Moving on.

> Dependencies, Exclusions, and "Require one-of"
>
> With P::V I can do this:
>
> { credit_card_number =>
> { optional => 1,
> depends => [ 'credit_card_expiration', 'credit_card_holder_name' ] },
>
> credit_card_expiration => { optional => 1 },
>
> credit_card_holder_name => { optional => 1 },
> }
>
> I have no idea how I might do this in Perl6, but I would love to see it
> supported as part of parameter declarations

You sortof can:

sub validate (+$credit_card_number,
+$credit_card_expiration,
+$credit_card_holder_name)
where { defined $credit_card_number xor
defined $credit_card_expiration &&
defined $credit_card_holder_name }
{...}

But that's really yucky.

> Similarly, something I've wanted to add to P::V is exclusions:
>
> { credit_card_number =>
> { optional => 1,
> excludes => [ 'ach_bank_account_number' ] },
> }
>
> Another thing that would be really nice would be to require one of a set
> of parameters, or one set out of multiple sets, so we could say "we need
> credit card info _or_ bank account info".

Yeah, I suppose that would be nice. However, when you're doing these
kinds of complex dependencies, you'd like to provide your own error
messages when they fail. That is, instead of:

'$credit_card_number excludes $ach_bank_account_number'

You could say:

'You can't give a credit card number and a bank account number, silly!'

So I wonder whether this kind of logic is better for a P::V module in
Perl 6. Let somebody else think about the hard stuff like that.

> Transformations
>
> Another potential future feature for P::V is the ability to specify some
> sort of transformation callback for a parameter. This is handy if you
> want to be flexible in what inputs you take, but not explicitly write code
> for all cases:
>
> { color => { regex => qr/^(?:green|blue|red)$/i,
> transform => sub { lc $_[0] } }
> }
>
> I suspect that this could be implemented by a user-provide trait like "is
> transformed":
>
> sub print_error ($color where m:i/^ [green | blue | red] $/ is transformed { lc })
>
> Presumably this can be done with the existing language. It doesn't add
> anything at compile time, so it really doesn't need to be part of the
> language.

Even things that do add things at compile time don't need to be part
of the language. That's why "use" is a macro. :-)

Luke

Yuval Kogman

unread,
Aug 17, 2005, 7:03:00 PM8/17/05
to Luke Palmer, Dave Rolsky, perl6-l...@perl.org
On Wed, Aug 17, 2005 at 22:06:07 +0000, Luke Palmer wrote:
> >
> > { credit_card_number =>
> > { optional => 1,
> > depends => [ 'credit_card_expiration', 'credit_card_holder_name' ] },
> >
> > credit_card_expiration => { optional => 1 },
> >
> > credit_card_holder_name => { optional => 1 },
> > }
> >
> > I have no idea how I might do this in Perl6, but I would love to see it
> > supported as part of parameter declarations
>
> You sortof can:
>
> sub validate (+$credit_card_number,
> +$credit_card_expiration,
> +$credit_card_holder_name)
> where { defined $credit_card_number xor
> defined $credit_card_expiration &&
> defined $credit_card_holder_name }
> {...}

multi sub validate () { # no credit card info

}

multi sub validate (
$credit_card_number,
$credit_card_expiration,
$credit_card_holder_name
) {

}

--
() Yuval Kogman <nothi...@woobling.org> 0xEBD27418 perl hacker &
/\ kung foo master: /me beats up some cheese: neeyah!!!!!!!!!!!!!!!!!

Dave Rolsky

unread,
Aug 18, 2005, 12:41:52 AM8/18/05
to Luke Palmer, perl6-l...@perl.org
On Wed, 17 Aug 2005, Luke Palmer wrote:

>> Dependencies, Exclusions, and "Require one-of"
>>
>> With P::V I can do this:
>>
>> { credit_card_number =>
>> { optional => 1,
>> depends => [ 'credit_card_expiration', 'credit_card_holder_name' ] },
>>
>> credit_card_expiration => { optional => 1 },
>>
>> credit_card_holder_name => { optional => 1 },
>> }
>>
>> I have no idea how I might do this in Perl6, but I would love to see it
>> supported as part of parameter declarations
>
> You sortof can:
>
> sub validate (+$credit_card_number,
> +$credit_card_expiration,
> +$credit_card_holder_name)
> where { defined $credit_card_number xor
> defined $credit_card_expiration &&
> defined $credit_card_holder_name }
> {...}
>
> But that's really yucky.

Hideous, indeed. Presumably with macros or some other compile time thing
that can be turned into something more palatable.

>> Similarly, something I've wanted to add to P::V is exclusions:
>>
>> { credit_card_number =>
>> { optional => 1,
>> excludes => [ 'ach_bank_account_number' ] },
>> }
>>
>> Another thing that would be really nice would be to require one of a set
>> of parameters, or one set out of multiple sets, so we could say "we need
>> credit card info _or_ bank account info".
>
> Yeah, I suppose that would be nice. However, when you're doing these
> kinds of complex dependencies, you'd like to provide your own error
> messages when they fail. That is, instead of:
>
> '$credit_card_number excludes $ach_bank_account_number'
>
> You could say:
>
> 'You can't give a credit card number and a bank account number, silly!'

Actually, I forgot to mention this in my original post, but in general
it'd be nice to be able to provide some sort of callback/object to be
called whenever a parameter check fails, and it'd be nice to be able to
provide more than one, so I can have custom parameter exception logic per
class or sub.

> So I wonder whether this kind of logic is better for a P::V module in
> Perl 6. Let somebody else think about the hard stuff like that.

It'd be nice to catch this at compile time whenever possible, though.

>> Presumably this can be done with the existing language. It doesn't add
>> anything at compile time, so it really doesn't need to be part of the
>> language.
>
> Even things that do add things at compile time don't need to be part
> of the language. That's why "use" is a macro. :-)

Yes, but see above. I know we can do things like add syntax at compile
time, but can we do these sorts of checks? I'm sure the answer is yes,
but how easy will it be? Of course, if it's implemented via a C6AN module
it's only got to be done once, but it's worth thinking about.

Dave Rolsky

unread,
Aug 18, 2005, 12:45:52 AM8/18/05
to perl6-l...@perl.org
On Wed, 17 Aug 2005, Dave Rolsky wrote:
> Type Validation, "isa", & "can"
>
> Params::Validate allows for several ways to check the _value_ of a parameter.
> One way is to specify a primitive type like "SCALAR" or "ARRAYREF". In P6 we
> have that with this:
>
> sub date (Scalar +$year is required, ...)
>
> I'm not sure is "Scalar" is a valid type though, but that's ok because we
> have better types built in. In this case we should really use "Int" for a
> year.

And another question. How will I make Perl6 not do automatic coercion for
me. If I have this sub:

sub date (Int +$year is required, +$month, +$day)

and someone does this:

date('this year', 12, 1);

I'd prefer for this to fail, rather than giving me 0000-12-01! I vaguely
remember a mention of "use strict 'types'" either on this list or hanging
out with some pugs folks at YAPC.

Dave Rolsky

unread,
Aug 18, 2005, 12:43:43 AM8/18/05
to perl6-l...@perl.org
On Thu, 18 Aug 2005, Yuval Kogman wrote:

>> You sortof can:
>>
>> sub validate (+$credit_card_number,
>> +$credit_card_expiration,
>> +$credit_card_holder_name)
>> where { defined $credit_card_number xor
>> defined $credit_card_expiration &&
>> defined $credit_card_holder_name }
>> {...}
>
> multi sub validate () { # no credit card info
>
> }
>
> multi sub validate (
> $credit_card_number,
> $credit_card_expiration,
> $credit_card_holder_name
> ) {
>
> }

Yeah, while playing with datetime stuff for pugs it occurred to me that
providing a fallback multi sub could be quite handy.

But I'd really like to get this stuff done at compile time wherever
possible. If I write this:

validate( credit_card_number: $number );

it should blow up at compile time, right?

Autrijus Tang

unread,
Aug 18, 2005, 1:04:56 AM8/18/05
to Dave Rolsky, perl6-l...@perl.org
On Wed, Aug 17, 2005 at 11:45:52PM -0500, Dave Rolsky wrote:
> And another question. How will I make Perl6 not do automatic coercion for
> me. If I have this sub:
>
> sub date (Int +$year is required, +$month, +$day)

BTW, Pugs supports the ++ syntax, which iirc is said to be back in favour
during the Oscon design meeting:

sub date (Int ++$year, +$month, +$day)

> and someone does this:
>
> date('this year', 12, 1);
>
> I'd prefer for this to fail, rather than giving me 0000-12-01! I vaguely
> remember a mention of "use strict 'types'" either on this list or hanging
> out with some pugs folks at YAPC.

You will probably get:

1. a compile time warning of unsafe coercion, possibly made fatal.
and
2. a NaN at runtime if you ignore the warning.

Thanks,
/Autrijus/

Larry Wall

unread,
Aug 18, 2005, 1:11:38 AM8/18/05
to perl6-l...@perl.org
On Thu, Aug 18, 2005 at 01:04:56PM +0800, Autrijus Tang wrote:

: On Wed, Aug 17, 2005 at 11:45:52PM -0500, Dave Rolsky wrote:
: > And another question. How will I make Perl6 not do automatic coercion for
: > me. If I have this sub:
: >
: > sub date (Int +$year is required, +$month, +$day)
:
: BTW, Pugs supports the ++ syntax, which iirc is said to be back in favour
: during the Oscon design meeting:
:
: sub date (Int ++$year, +$month, +$day)

Yes.

: > and someone does this:


: >
: > date('this year', 12, 1);
: >
: > I'd prefer for this to fail, rather than giving me 0000-12-01! I vaguely
: > remember a mention of "use strict 'types'" either on this list or hanging
: > out with some pugs folks at YAPC.
:
: You will probably get:
:
: 1. a compile time warning of unsafe coercion, possibly made fatal.
: and
: 2. a NaN at runtime if you ignore the warning.

In this case it shouldn't get even that far since you'll get a fatal
error that says you tried to pass a positional list to a non-positional
parameter. + isn't a synonym for ?.

Larry

Yuval Kogman

unread,
Aug 18, 2005, 2:47:37 AM8/18/05
to Dave Rolsky, perl6-l...@perl.org
On Wed, Aug 17, 2005 at 23:43:43 -0500, Dave Rolsky wrote:

> But I'd really like to get this stuff done at compile time wherever possible.
> If I write this:
>
> validate( credit_card_number: $number );
>
> it should blow up at compile time, right?

So should MMD: The type signatures are rigid, and the moment things
get closed (no more MMD alternatives are possible), if your
dispatches don't have any MMD candiates it's just as much a type
error as a normal sub with a bad type.

--
() Yuval Kogman <nothi...@woobling.org> 0xEBD27418 perl hacker &

/\ kung foo master: *shu*rik*en*sh*u*rik*en*s*hur*i*ke*n*: neeyah!!!!

Dave Rolsky

unread,
Aug 18, 2005, 12:03:22 PM8/18/05
to perl6-l...@perl.org
On Thu, 18 Aug 2005, Autrijus Tang wrote:

> On Wed, Aug 17, 2005 at 11:45:52PM -0500, Dave Rolsky wrote:
>> And another question. How will I make Perl6 not do automatic coercion for
>> me. If I have this sub:
>>
>> sub date (Int +$year is required, +$month, +$day)
>
> BTW, Pugs supports the ++ syntax, which iirc is said to be back in favour
> during the Oscon design meeting:
>
> sub date (Int ++$year, +$month, +$day)

Uh, great, what's the syntax mean again?

It _looks_ like "+" as a prefix now means "must be passed as a name param"
and "++" means must be passed as a named param and is required. Seems
good to me.

> You will probably get:
>
> 1. a compile time warning of unsafe coercion, possibly made fatal.
> and
> 2. a NaN at runtime if you ignore the warning.

Excellent. And presumably #1 will be activated by some lexically scoped
pragma like "use strict 'types'"?

Hurry up and finish. I want to use this language, darnit! And yes, I
know about pugs, obviously, but for production usage I need less of a
moving target ;)

Larry Wall

unread,
Aug 18, 2005, 12:53:45 PM8/18/05
to perl6-l...@perl.org
On Thu, Aug 18, 2005 at 11:03:22AM -0500, Dave Rolsky wrote:
: Hurry up and finish. I want to use this language, darnit! And yes, I
: know about pugs, obviously, but for production usage I need less of a
: moving target ;)

Yes, Perl 6 is a moving target--but one of the most bothersome facts
of life is that, to get anywhere you're not, you have to move...

Larry

Chromatic

unread,
Aug 18, 2005, 1:02:23 PM8/18/05
to Dave Rolsky, perl6-l...@perl.org
On Wed, 2005-08-17 at 23:43 -0500, Dave Rolsky wrote:

> But I'd really like to get this stuff done at compile time wherever
> possible. If I write this:
>
> validate( credit_card_number: $number );
>
> it should blow up at compile time, right?

Does that depend on how closed you want Perl 6 to think your world is at
compile time?

-- c

Autrijus Tang

unread,
Aug 18, 2005, 1:06:52 PM8/18/05
to chromatic, Dave Rolsky, perl6-l...@perl.org
On Thu, Aug 18, 2005 at 10:02:23AM -0700, chromatic wrote:
> On Wed, 2005-08-17 at 23:43 -0500, Dave Rolsky wrote:
>
> > But I'd really like to get this stuff done at compile time wherever
> > possible. If I write this:
> >
> > validate( credit_card_number: $number );

BTW, the colon is on the left:

:credit_card_number($number)

> > it should blow up at compile time, right?
>
> Does that depend on how closed you want Perl 6 to think your world is at
> compile time?

Right, because introducing new multi variant at runtime is a
desired feature. Which is why I think "closed" should not be
limited to classes, but should extend to packages as well...

Thanks,
/Autrijus/

Reply all
Reply to author
Forward
0 new messages