develooper Front page | perl.perl6.language | Postings from September 2005


Thread Next
Yuval Kogman
September 25, 2005 10:29
Message ID:
Hmm... Making up these subjects is fun =)


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

	my $dog =;

	if ($condition) {
		my Cat $c = $dog;
	} else {

since it's guaranteed to be a runtime error if $condition is ever

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 <> 0xEBD27418  perl hacker &
 /\  kung foo master: /me supports the ASCII Ribbon Campaign: neeyah!!!

Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About