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:
> A) Omit the #3 check from compile time; at runtime, use the actual
> type of $x. The "returns" type annotation will not propagate
> outward to the caller.
>
> At compile time, check for #2: Any.does(Any)
> At runtime, check for #2: "abc".does(Any)
> check for #3: "abc".does(Str)
This is the view that says (returns Foo) amounts to declare a:
my sub return (Foo $x) { &*return($x) }
and perform no static checking for return types to match their calling
context. It's got the "dynamic language" feel, which means practically
no nontrivial type errors will happen at compile time, because function
calls, regardless of its declared return type, can be used in any type
context.
> 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.
> C) Make the return type observe both #2 and #3 at compile time,
> using junctive types to pass both checks:
>
> sub id ( Any $x ) returns Any|All { return($x) }
This is similar to the approach taken by OO-style local type
inferencers; see the "Colored local type inference" paper for details.
The idea is that, if one omits the "returns" declaration from a function
of undecidable type, the inferencer can silently fill in (Any|All) and
make the program compile, effectively defer typechecks to runtime.
On the other hand, if the user does provide a type annotation, then both
#2 and #3 will be observed, and type errors can occur. It's closer to
the "soft typing" or "incremental typing" idea.
> D) Make the return type observe both #2 and #3 at compile time,
> using type variables:
>
> sub id ( (::T) $x ) returns ::T { return($x) }
And this is a natural extension to guide the inferencer so it won't be
totally giving up on polymorphic functions such as &id. C) and D) can
be taken together, resulting to a powerful soft typed language.
However, if we take the view that type annotation are merely storage
allocation hints and runtime coercers, then A) is probably the way to go.
Thanks,
/Autrijus/
pgpcVsbqfgSlq.pgp
Description: PGP signature
