Hmm... Making up these subjects is fun =) Anywho...
Since type inferrencing is going to make into Perl 6, and
allomorphism is very richly supported by the type system, i'm
wondering on the nature of the optionality...
What excatly do the users get to control? Are functions with '-->'
rich type signatures going to limit the user in any way? What should
the functions in the prelude be defined as?
Under strict type inferrencing, i'd expect this to be a compile time
error:
my $dog = Dog.new;
if ($condition) {
my Cat $c = $dog;
} else {
...
}
since it's guaranteed to be a runtime error if $condition is ever
true.
Is there any situation where a compile time error is not a good
thing to have?
If allomorphism is enough such that the class that implements the
actual integers, which does Str, Int, Num, Ord and all that for the
yummy operations we can do on it, and expressions like
"foo" ~ 42 ~ "Bar"
are type safe, is there really any reason to ever not give compile
time errors to type errors?
Also, is it rational to say, within a lexical pragma, that such
zealous allomorphism is prohibited, in order to get more rigid type
semantics for that block? If so, how is this defined?
On the other side of the spectrum, is there any situation where type
safety is ever a bad thing, if it's inferred, and flexible?
--
() Yuval Kogman <[EMAIL PROTECTED]> 0xEBD27418 perl hacker &
/\ kung foo master: /me supports the ASCII Ribbon Campaign: neeyah!!!
pgpPThiBbNSi3.pgp
Description: PGP signature
