--- Damian Conway <[EMAIL PROTECTED]> wrote:
> Austin Hastings wrote:
>
> > In this case, I rather like the idea of being able to say
> >
> > sub foo(@a is Array of Int) {...}
> >
> > my @input = read_a_bunch_o_data();
> > foo(@input);
> >
> >
> > Where the compiler will automatically "wrap" the @input array in a
> > make-it-an-int converter. This, to me, is DWIM.
>
> But to many others it's not DWIS ("Do What I Said"). To them, types
> are about compile-time checking of constraints on the run-time
> compatibility of data.
No problem so far. And when they run -w, perl should tell them
"subroutine call not provably (in)correct at line 3"
> So they would argue that declaring C<foo> like that implies that any
> argument passed to C<foo> ought to guarantee that it already
> contains Ints, rather than specifying a (possibly unsuccessful)
> run-time coercion to ensure that condition.
But what's the vision for p6?
My expectation is that the type-checking stuff will be heavily used
for:
1- Large scale projects.
2- CPAN modules.
I expect that the folks who want to do one-liners will still want to be
able to say C<perl6 -MCPAN whatever>
So the "strict" bits have to be forgiving of the "non-strict" callers.
To me, the way around this is NOT to force interface contracts down to
some lowest common denominator, but rather to document what is
expected, and then allow the developer to accept responsibility for
stepping on his crank.
If you say, "Give me an Array of Hash of (String => Array of BigNum)"
and I say, "Here's an Array of Scalars. They're OK, I promise" and
things "gang agley", it's my fault. I can deal with that.
And if you have said "Array of Hash of (String => Array of BigNum)"
then I can theoretically give you a typed array and let the compiler
check it.
However, if you have been forced to say "Give me an Array" in the
interests of avoiding typewhacking one-liners, then (1) you've got to
check and throw the exception, slowing up your code; and (2) there's no
option for me if I *DO* want to conform to the rigid rules.
> And many would argue that implicit coercions on typed
> parameters is one of the major *problems* with C++.
Of course it is. And why is that? Because they've GOT strongly typed
parameters, but sometimes the data doesn't match the signature. This
has been exacerbated by differentiating const from non-const types, and
by that foul fire-hose of code known as the template mechanism.
But at the bottom, the C++ problem is a problem of its own making --
people want coercion. Just like me. I want coercion. I want the ability
to take advantage of the really nifty, carefully written code available
from dedicated, rigorous hackers like this Conway fellow. But I want to
do it as a slap-dash hack with no thought given to type stuff. How?
>
> My own problem with this wrapping notion is that I consider it
> incompatible with the reference semantics of normal Perl 6
> parameters. Specifically, I *don't* want the aliasing mechanism to
> be capable of implicit type coercions.
Maybe you could expand on that a little?
> On the other hand, I have *no* problem with this:
>
> sub foo(@a is Array of Int is copy) {...}
> ^^^^^^^
> doing the kind of coercive wrapping you're suggesting.
What's the difference? (Aside from the obvious, that is...)
> > I think there may be a library of wrapper "helper-functions" used
> by
> > both the compiler and module-writers. Things that do coercive
> behavior
> > rather than try-but-maybe-fail behavior.
>
> Quite possibly. Though wrapping is probably too "heavy" a mechanism
> for type
> coercions. When I imagine type coercions in Perl 6, I imagine them as
> compile-time detectable, and explicit.
Ahh, but if you don't want heavy, just comply with the expected type,
or do your own coercion. I certainly imagine them as compile-time
detectable (I don't want all subcalls to be wrapped), but obvious,
implicit coercions should get a configurable warning and a wrapper.
sub foo(@a of Scalar) {...}
foo(1, 2, 3); # OKAY
foo(@a, @b, @c); # WARNING: foo(List of Array) will be coerced to
foo(Array of Scalar) using &foo.wrap(__flattenArrays)
foo(**(@a, @b, @c)); # OKAY: Fixed it using SuperMario operator.
> > So the "use strict signatures;" wouldn't be a switch invoking type
> > stricture, per se. What it would do is convert from "DWIM
> > stricture" to "Patriot Act stricture".
>
> I still believe that the default level of type-checking you're
> proposing is the wrong way round.
Hmm. Okay. I'll let you reverse the default levels if you give me a
single-letter command line switch to go back to "slouch-mode"..
=Austin
