John M. Dlugosz wrote: |Perl 6| wrote:
in. Er, so would:
my CGI::Simple $x .= new;
my $y =;

mean that:
$x <whatever the compare class operater is> $y

is not true? Or would there be a way to tell them apart, on a class (?) level.

The actual dynamic type at run time of the values in $x and $y are both CGI::Simple.

The static compile-time type of $y is Any.
These are consistent with what I understand.


will give a compile-time error if nosuchmethod is not declared as part of CGI::Simple.
Is this spec'd somewhere? I don't think we can statically know what methods CGI::Simple will have at compile time. What if I do a "class CGI::Simple is also { method nosuchmethod() { ... } }" inside an eval? Then it does have the method by the time we get to instantiating it, and calling the method. I think Perl 6 is just too dynamic to do these kinds of checks, without using some kind of additional (not the default) pragma saying "I promise that classes don't get changed at runtime".


will look it up when the attempt is made, and only then fail. (Or succeed if something funny is going on and it exists =now= but wasn't declared originally. There are a few documented ways to be funny already.)
Right, but I don't know that being funny should preclude you from being able to write a type constraint on a variable that makes sure we never assign anything to it that isn't "compatible" with CGI::Simple. Making "$x.nosuchmethod;" fail at compile time by default would stop you using them that way in the cases where there are more subtle things going on.

I've kinda come to view Perl 6's types, unless you ask them to be more than this, as a way of saying "make sure X never can happen at runtime and complain if it does", as well as giving the compiler more chances to optimize various things, rather than allowing us to do a load of type-checking stuff statically and fail at compile time. The "subset" types can be as complex as you like, so you can't check them statically at all, since it boils down to the halting problem, which is one thing I don't think we should require people implementing Perl 6 compilers to have to solve. ;-)


Reply via email to