At 11:47 PM 9/3/2001 -0400, Ken Fox wrote:
>"Bryan C. Warnock" wrote:
> > {
> > my $a = sub ($$) { code };
> > gork($a);
> > }
> >
> > sub gork {
> > my ($a) = shift;
> > $a->(@some_list); # <- Here
> > }
> >
> > The reason prototypes aren't checked at "Here" is because there really
> > isn't a way to know what the prototype was.
>
>Um, that's not true. ML can do stuff like that -- all automatically and
>without any type declarations.
We can't, at least not at compile time. Something like:
sub foo::bar($$);
sub baz::bar(\@);
$ref = rand > .5 ? \&foo::bar : \&&baz::bar;
$ref->(@array);
makes it difficult. I think we're going to need a "call as list" form of
the sub preamble for the "I can't check at compile time" cases.
>What happens is the type of gork's $a is determined, which cascades
>to the type of gork's $_[0], which cascade's to your first block's $a.
>ML even has polymorphic functions where the output type depends on the
>input type.
>
>It is possible. It's just a question of whether we want to do it.
Oh, sure, but it's mostly runtime checking. Personally I'd prefer to avoid
it where possible since we can pick up speed wins by avoiding it. I'm now
convinced we can't always avoid it, so we'll just have two function entry
points for prototyped functions and do runtime type
checking/dispatch/whatever at runtime where we have to.
I'm beginning to miss the days when a function call was just a function
call... :)
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
