Front page | perl.perl6.language |
Postings from July 2005
Re: The meaning of "returns"
Thread Previous
From:
Autrijus Tang
Date:
July 27, 2005 15:24
Subject:
Re: The meaning of "returns"
Message ID:
20050727222534.GA32639@aut.dyndns.org
On Thu, Jul 28, 2005 at 05:57:28AM +0800, Autrijus Tang wrote:
> On Thu, Jul 28, 2005 at 05:03:05AM +0800, Autrijus Tang wrote:
> > Hence, it seems to me that there are only four ways out:
>
> Some annotations copied from discussion in #perl6:
Last time I reply to myself on this thread, hopefully. :-)
> > B) Omit the #2 check from both compile time and runtime; this allows
> > us to write the "returns All" version.
> >
> > At compile time, check for #3: All.does(Str)
> > At runtime, check for #3: "abc".does(Str)
>
> This is quite absurd, and was included only for completeness.
On second thought, this is not as absurd as it seems. This view is that
"sub f () returns Foo" means "f() can be used in any place that a Foo
literal can occur", which means that it can be used in contexts that
demands a supertype of Foo (like Any), but never a subtype of Foo.
The language defined this way would still be dynamic; disabling #2 means
that the type of $x will not be checked against Foo upon return($x), so
anything at all can be used in that position. Meaningful type errors
can occur, for example when saying close(length("abc")), where length
would have "returns Int" and close have a "IO" parameter.
However, this does require the curious device of "returns All" as the
default return type, unless we eliminate that using type variables
and/or type inferencing, at which time we can get #2 back for free and
implement full static typechecking anyway.
Thanks,
/Autrius/
Thread Previous