[Grace-core] Typing of Number

[James Noble]

> Also, Michael's lament:
> 
>> with the "once inexact,
>> always inexact" behaviour you'd [often] end up with "everything inexact",
>> since you could never tell if you'd introduced an inexact type
>> somewhere along the line (perhaps from an argument). 
> 
> This sounds a bit like wishing that π were 3.  That _would_ make everything simpler ... but it just ain't so.

This is also an argument that the static type system should be able to track this distinction. 


> The double-dispatch will behave like a distributed typecase.  If we want to actually honor our intention to allow library builders to add new representations of numbers, then we better use double-dispatch rather than a big typecase in every operation.

Hmm. I thought about this and I'm not really sure it matters either way.
Realistically you'll need to extend all of the existing numeric classes
anyway to add a new representation.

>> I can't see why we'd do more implicitly than Go does.
> 
> I can't see what rule we might use to trigger implicit type conversions.  Are you going to suggest one,or are we sticking to our guns for now?

Some of Michael's code had a (semi-) implicit .asRational call in the middle of it I think.
I'd prefer we stick to our guns.  It should simplify things.
But then Number+Number->Number really doesn't tell the whole story....

> 
>> PS: Go's identifier rules - Rob Pike probably knows as much about unicode programing languages as anyone.
>> 
>> It was important to us to extend the space of identifiers from the confines of ASCII. Go's rule—identifier characters must be letters or digits as defined by Unicode—is simple to understand and to implement but has restrictions. Combining characters are excluded by design, for instance. Until there is an agreed external definition of what an identifier might be, plus a definition of canonicalization of identifiers that guarantees no ambiguity, it seemed better to keep combining characters out of the mix. Thus we have a simple rule that can be expanded later without breaking programs, one that avoids bugs that would surely arise from a rule that admits ambiguous identifiers.
> 
> 
> This seems like a reasonable rule — although we would allow APOSTROPHE (Unicode 0027) in addition to class    It would exclude the tricky cases with combining character about which Michael was fretting.  I'm not actually sure that a Unicode NUMBER is; does it include, for example, TAMIL NUMBER TEN (Unicode 0BF0)?

I don't know either, but as Rob Pike says, it does avoid a lot of difficult cases.
Michael - what do you think?

James
> 
> 	Andrew