On Wed, Jan 18, 2006 at 09:38:04AM +0800, Audrey Tang wrote:
: Also, would you be happy with different treatments of Int/Int versus
: Num/Num?
:       0/0     # fail "illegal division by zero"
:       0.0/0.0 # NaN

I'd like to point out that there's no reason in principle that a failure
undef can't return NaN in numeric context, so we don't actually have
to distinguish those two cases normally (though "use fatal" might
distinguish them).

By and large I agree with Darren.  The boxed types should opt for
consistency over efficiency while the unboxed types should opt for
efficiency of consistency.  So perhaps we just say that boxed NaN is
indistinguishable from undef--in particular, unboxing one in numeric
context gives you back the NaN.  I don't know whether it makes sense
to extend that to ┬▒Inf though.  Maybe it does.  We're kinda fuzzing
that idea anyway already.  Undefined numbers vary in definedness much
like undefined generic prototype objects, aka "classes".

All undefs are created unequal, but some are more unequal than others.

Long term I think we'll end up asking these objects whether they're
defined according to one of their roles.  So the infinities know they
have a defined sign, for instance, but not a defined magnitude (except
insofar as infinity is considered a separate defined concept).  And
an object might be considered defined as a Mammal but undefined (so far)
as a Dog or Cat.  So instead of $num.defined or $animal.defined we
might have $num.defined(Sign) or $animal.defined(Dog|Cat).  If you
omit the arg then .defined devolves to something like what we have now,
where the definedness is decided by the class of the object.

Note this is not quite the same as .does(Dog|Cat), since an undefined
proto object returns true for that but false for .defined(Dog|Cat) unless
one of those roles thinks the object is sufficiently initialized to
be considered defined.  For most roles that could implicitly determined
by whether the BUILD for that role has run, assuming BUILD always
produces a complete initialization.

Maybe "defined" is the wrong word for it anymore.  It's more like "okay"
or "normal" or "nominal" or "functional".  I could go for $Fido.good(Dog). :-)


Reply via email to