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). :-) Larry
