[Grace-core] Typing of Number

[James Noble]

Well I think there are a bunch of things going on here 
and it's not obvious what the Right Thing to do is...

> My sense is that we believed that Number should be the only numeric TYPE.  There would be many classes that implemented it, such as Rational, ComplexRational, Binary64, etc.  Maybe there is some very clever way that will let these be types, but I don't see it.

Number should certainly be a type; all these classes/types should be subtypes of Number.

>> it's unclear what
>> the type of Binary64 + Rational should be, with reasonable arguments
>> for different results.
> 
> It seems to me that the CLASS of the result has to be Binary64.  Whenever one does arithmetic with inexact numbers, the result must surely be an inexact number.  Maybe multiplying by exact zero is an exception, but in general, once inexact, always inexact

I like the rules from Rob Pike's Go here: there are no implicit conversions.
So this could be a static (or dynamic) error.

that raises the questions of the types of things like "+" and how we define them.

DRuby (at least) as union & intersection types. So e.g. the types of + 
could be Rational + Rational, Integer64 + Integer64, etc... 
rather than Number + Number... (hmm, but perhaps this doesn't
make that much sense). If we want implicit conversions we
could have Number+Number *as well as* more specific types

> But the implementors of the libraries need to write the methods that make the new numbers work with the others.
> For this purpose we need to very carefully design the protocol for Number, so that implementors of various Number classes know what they can expect from their arguments.  This will probably some rather confusing double-dsipatch protocol, analogous to Smalltalk's "convert to number and send".
> 
>> It seems that they will all need to be coercible to Rational in order
>> for that to work, and consequently the return type of Number
>> operations is the dynamic type of the receiver


> We can coerce exact numbers to Rational, but not inexact numbers.  The (static) return type of an operation can depend only on the (static) types of the arguments, not on their values, or on their dynamic type, because doing otherwise means that we don't have static typing.  That is exactly why I think that Number must be the only type.

yep... the catch is, for an hypothetical efficient implementation, 
(or more pragmatically for calling C)  we need things like Integer64 to go nicely
into machine integers. I can see how to get this (especially if I can write exact
"class types" like =Integer64 which don't permit subtyping) but I think we need
more than just Number - although you should be able to get away with just
Number through second year if people don't want anything more, people
should be able to teach more about numeric types if they want to.

at least that would let us have numeric operators like 

<T extends Number> method +(self : T, other : T) -> T 

although I don't know how to write that in Grace syntax
(without the "bad idea" of an explicit self parameter)

> Note that correct arithmetic comes first.  If the type system won't permit correct arithmetic, then the type system needs to be fixed, not the other way around.  So no type system can ever make 2*(2+i) = 4.  Indeed, recall that the types can never affect the results of a computation; all that they can do is give advance warning that a given computation might go wrong.

yes and yes - not that that gives us a solution, but it does help explore the problem space!

J