develooper 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


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About