Add a vtable function to get arithmetic mode

[whiteknight]

After talking with Allison yesterday, I would like to suggest that we add a new VTABLE_get_numeric_mode(). This VTABLE would return a flag value to determine whether the PMC should be treated as an INTVAL or a FLOATVAL in an arithmetic calculation.

Currently we have a large series of mathematics vtables that are called from the math.ops. These mathematics vtables allow the PMC to determine how it participates in the operation. The downside to this setup is that we need a large number of vtables for all supported operations.

For every operation where we do not have a corresponding vtable, we must decide whether to treat the PMC as an INTVAL or a FLOATVAL, a decision which is going to create problems for some types.

Having a VTABLE interface that allows the PMC type to describe whether it is int-like or float-like will allow us to encapsulate more operations better, and make better decisions in more situations. Also, it will allow us to slim down the VTABLE structure to remove a few operations which are rarely used except in numerical types and only to make these decisions for us.

Alternatively to a new VTABLE function, we could have some sort of flag mechanism in the VTABLE structure and check it with a macro.

I suggest we need at least three outcomes: A PMC is either int-like, float-like, or non-numeric. Attempting to perform a non-overridden math op on a non-numeric PMC could throw a meaningful error instead of just falling back to the implementation in default.pmc.

Opinions and comments much appreciated

[coke]

Instead of a vtable or a flag, I would recommend cleaning up the 'does' interface (already available via a VTABLE and exposed in an opcode.)

I would also suggest that instead of checking the flag to see if we should throw an error, you should probably just make the get* variants throw errors on default. Overriding them on Integer/Float to return the appropriate value works, as most HLL implementors are just going to subclass the core variants.

The operations themselves are going to eventually going to ask the PMC for its int value or float value before manipulating the value - I'm not convinced yet that it's necessary for have a generic op type that would need to ask the PMC how it wants to be treated - having separate op variants for int vs. float vs. string does not seem /too/ onerous.