On 12/17/05, Darren Duncan <[EMAIL PROTECTED]> wrote:
[snip]
> 2. Until a value is put in a container, the container has the
> POTENTIAL to store any value from its domain, so with respect to that
> container, there are as many undefs as there are values in its
> domain; with some container types, this is an infinite number.
>
> Only a container that can have exactly one possible value can be
> equated with; but then you have a constant.
>
> In a manner of speaking, an undef is like a quantum superposition, in
> that it has no specified value, but rather all possible domain values
> at once, so you can not absolutely say it is equal to anything.
So, in essence, you're saying that undef === one( #the domain of the
type# ) ... I'm not sure I'm comfortable with that. If I have an undef
of a constrained type and I compare it to a value of some other
constrained type whose domains don't overlap, then, by this
definition, I -can- say something about the truth value. For example,
if I define EvenInt and OddInt in the obvious ways, then the following
should hold:
my EvenInt $e;
my OddInt $o;
if ( $e != $o ) { say "This should print out." }
I'm not sure that works with the Principle of Least Surprise. While I
cannot say what it is, you're saying that I can now say what it isn't.
While that follows from typing, that doesn't follow from the common
understanding of undef.
Rob
