Oh goody, two with one blow:

--- Damian Conway <[EMAIL PROTECTED]> wrote:
> Larry wrote:
> 
> > : >  multi foo (@a is Array of int) {...}
> > : >
> > : >  my int @a = baz();     # is Array of int
> > : >  my     @b = baz();     # is Array of Scalar
> > : >
> > : >  foo(@a);    # @a is typed correctly, so OK
> > : >  foo(@b);    # @b is not explicitly typed as C<int>; OK or
> FAIL?
> > : 
> > : Fails.
> > : 
> > : Because:
> > : 
> > :   not (Array of Scalar).isa(Array of int)
> > : 
> > : Which in turn is because:
> > : 
> > :   not Scalar.isa(int)
> > 
> > I dunno.  I can argue that it should coerce that.  It'll certainly
> be
> > able to coerce a random scalar to int for you, so it's not a big
> stretch
> > to coerce conformant arrays of them.  On the other hand, it's
> likely
> > to be expensive in some cases, which isn't so much of an issue for
> > single scalars/ints/strs.

I saw a description in A6 saying that an Array of Foo was basically a
function which mapped int to Foo.

That being the case, a coercive @scalars -> @ints "cast" used to
translate an array parameter would really be a "wrapped" (function
mapping ints to scalars) whose wrapper converted the returned result to
ints.

Is there going to be some generic way to do this?

That is: Can I say 

SomeType @a; # extern, anyone?

sub SomeType2int(int)
    returns int
{
    my Some $some = call; 
    return 0 + $some;
}

@a.wrap(SomeType2int);

And having said that, then call:

sub b(@input is Array of int) {...}

b(@a);

> 
> Hmmmm. I guess it depends whether we treat type specifications as
> constraining the actual arguments, or restricting the interface of
> the formal parameters.
> 
> That is, does:
> 
>       multi foo (@a is Array of int) {...}
> 
> mean:
>       "Don't let them pass anything but an
>           Array of int-or-subclass-of-int"
> 
> or does it mean:
> 
>       "Let them pass Array of (anything)
>           and then treat the anythings as ints"
> 
> For my money, the former (i.e. compile-time type strictness) makes
> more sense 
> under pass-by-reference semantics, whereas the latter (i.e. run-time
> type 
> coercion) is more appropriate under pass-by-copy.

You're treading dangerously close to the S&M line there... 

Does it make sense to say C<use strict params;> for this stuff?

=Austin

Reply via email to