At 9:50 AM +0800 1/18/06, Audrey Tang wrote:
However, I think one of P6's idea is that the user should not have
to care between 0 and 0.0's behaviours, so maybe it makes sense to
do the same thing (be it NaN or exception) both ways.

I'm not sure that IEEE 754/854 still applies if we want to merge the
behaviours of int/num/complex/bigint/bigrat/bignum under a Num banner.

(There is always the worse-is-better option of going with whatever
the underlying runtime does, usually determined by hardware/libm.)

I think the best situation is that, at least with boxed types like Num, behaviour should be well defined, user friendly, and identical everywhere Perl 6 runs. There's no good reason to have different behaviour on different platforms; that allows implementation to leak through to the user when the user shouldn't have to know. And its also a very good source of bugs. Leave different behaviours to things that are explicitly connections to external resources, where it is reasonable for them to change.

As for unboxed types, I'm on the fence here, but you should probably let the implementation show through here, to an extent, since presumably the point of using unboxed types is to get bleeding edge maximum performance, and abstraction would take away from this then, maybe. Or maybe not. But if anything bleeds through, it should be the hardware, and not other programming languages.

-- Darren Duncan

Reply via email to