Nick Ing-Simmons <[EMAIL PROTECTED]> wrote:
> That is a Language and not an internals issue - Larry will tell us.
> But I suspect the answer is that it should "work" without any special
> stuff for simple perl5-ish types - because you need to be able to
> translate 98% of 98% of perl5 programs.
Sorry perhaps I didnt make myself clear - I was assuming that simple
types *would* continue to work as before (on the grounds that there's
really only one numeric type in perl5), but that because multiple core and
user-defined numeric types are a novel feature of perl6, perl6 *might*
need some extra syntax for type coercion etc.
Okay, how about this as a summary of what's been discussed so far:
(provisonal, subject to any language features or semantics TBA by Larry)
For numeric scalar types, there is a concept of 'bigness'. For binary
numeric operators, the op fn associated with the vtable of the 'biggest' operand
should be invoked. (For efficiency or ease of coding, the vtable fn of the smaller
operand *might* get called insead, but in this case that fn just forwards the
request to the fn associated with the big operand, possibly with arg swapping.)
A binop for a particular scalar type normally returns an SV of its own type.
At its discretion, it may return an SV of a 'smaller' type, if it is efficient
to do so, and if it results in no loss of accuracy.
The net effect is is that binops are executed in such a way as to minimise the
risk of overflow or loss of precision.
Dave M.
