[Grace-core] Typing of Number

[James Noble]

A few thoughts on Numbers:

First, I was thinking again about what the real beginners need: a
number "class" (or type, or whatever) that Just Works. Even early on,
people - especially if doing graphics early - will need to be able to
write number literals, compute with them pass them to libraries, print
them out etc. BASIC did this by using floats for everything, with a
built-in fudge factor (according to O'Reilly's MASTERMINDS OF
PROGRAMMING :-).  We don't have to do it that way, but we need to
provide the same ease: one "type" called Number that is all people
need to worry about.  This way, issues of floats vs integers etc can
be delayed until it is pedagogically necessary.  How many classes
implement that Number type?  At this level, it shouldn't matter - and
should hardly be visible.

Second, I talked about this with Jan Vitek, and his suggestion was to
look at MATLAB & R to see what they did about numbers. So I did, and,
well let's say they're pretty conventional. Matlab has singles
(floats) and doubles, signed and unsigned - 8,16,32 & 64 bit.  R has
vectors which an be either of doubles or integers.  So not much help
there - except, well, perhaps people do need to be able to teach about
the differences between doubles and integers in Grace --- and most
likely for storage and computation efficiency at least have types that
are vectors or arrays of integers or reals. 

Third, I still like the "no implicit conversion" rules. That doesn't
mean that e.g. the sqrt of a Rational can't be some kind of
FloatingPoint number with an _explicit_ operation --- but it should
mean that a given value of one class won't be converted to an instance
of another class e.g. during a function call.  

Where does that leave us?   I don't know!   Will structural typing help?

I guess we can have a type called Number, where all the operations are
have type Number.(Number) -> Number (however we write that!)  Most
APIs - at least most of the ones likely to be available at a low
"language level" should just be written in terms of Number.  How that
relates to the constellation of other numeric types, I've no idea!

Perhaps we can at least have an "abstract" type Numeric, where the
operations use selftypes - Numeric.(Selftype) -> Selftype - which will
set a general "scheme" for all the numeric types - but programs won't
in practice be able to do much with the that type, it's too general.
Rather, all it give is a place to define the general "shape" of the
numeric types -- and presumably could be used to write type-generic
methods and classes over the types.  The other numeric types would be
siblings of Number, with explicit conversions between them.

If methods are type-generic, then it shouldn't be too bad for
nonpolymorphic statically typed code, and presumably dynamically-typed
code calling unto statically typed code would somehow be able to
dynamically bind the generic parameter...

Would this work?  No idea!  At least it shows the simplest thing that
could possible work: just have _one_ Number class/type, and if we also
have Floating Point, well its a completely separate type.


  = = = = = = = = = = = = = = = = = = = = = = = = = = 


A peripherally related idea: we haven't talked about how generics work
in Grace - we need to do that.  We've got quite a nice story about the
relationships between class declarations, factory objects, and then
"instances" work together - how does that work with generics. Do we
have one generic factory, or many concrete factories that are
canonicalised?  How do the generic parameters?  If our generics really
are reified, what's the difference between type parameters and value
parameters? 

So one idea - suggested by a comment of Kim's - that Selftype
shouldn't be in the basic version of the language - is that we
recognise a real difference between ground, concrete classes, and
generic classes. The obvious way (Hello Ada!) is a "generic" keyword
on generic class declarations, at least as as hint that that this is
an advanced feature (and perhaps an environment could turn that
keyword off, thus all the associated features). So then class
declarations using Selftype, I guess, could also require the "generic"
keyword.  

  = = = = = = = = = = = = = = = = = = = = = = = = = = 

one for the Bad Ideas folder

Why not:

generic class Vector {
 Elems : Type, maxSize : Number -> 
 elements := Array.new(Elems,maxSize);
}

rather than:

generic class Vector<Elems> {
 maxSize : Number -> 
 elements := Array.new<Elems>(maxSize);
}

or whatever we have - OK well there are good reasons, not scaring the
horses being the biggest...