[Grace-core] Typing of Number

[James Noble]

You'd be better of double-dispatching:

 class Rational {
   method +(other : Number) -> Rational {
     other.addRational(self)
   }
 }

or, alternatively, using a big typecase:

class Rational {
   method +(other : Number) -> Rational {
       match(other) {
          case {Rational r -> self.addRational(r) }
          case {Machine.Integer64 m -> self.addInteger64(m) }
       // no else case, did we say that would raise a horrible error?
       }
   }
 }


> It isn't the static typing that determines the return type, but the
> dynamic type of the receiver, just like any other method.

Good... 

> It would
> work the same way without the types (and it does make 2*(2+i) == 4,
> assuming an implementation of Complex.asRational).

which is why we need to think about "no implicit conversions..."
(I'm not sure whether Go really does this, but it says
"Go does not support implicit type conversion. 
Operations that mix different types require casts (called conversions in Go).")

I can't see why we'd do more implicitly than Go does.

James


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.