[Haskell-cafe] Re: What does the Haskell type system do with"show (1+2)"?

[Cale Gibbard]

On 13/01/06, Brian Hulley <brianh at metamilk.com> wrote:
> Cale Gibbard wrote:
> >> <Snip>
> > So long as we're going to have a defaulting mechanism, it seems a bit
> > odd to restrict it to Num, and to classes in the Prelude.
>
> Instead of having literals such as 1 that could be Int, Integer, or Float
> etc, why not just have one Number type declared as something like:
>
> data Number = NInt Int | NInteger Integer | NFloat Float | NDouble Double |
> NRational Integer Integer | NComplex Number Number
>
> etc so that all numeric literals would just be translated by the compiler
> into a Number. Arithmetic ops would then not be overloaded but the compiler
> could hopefully optimize out the extra indirection caused by using Number
> instead of plain Int, Integer, etc.
>
> Regards, Brian.
>
>

This is not very extensible though. You can't extend that type later
with numeric types of your own (e.g. polynomials, power series, an
arbitrary precision computable real type, or some finite field).
Having a Num typeclass allows for users to add their own numeric types
at will. Also, implicit coercions would be required to implement the
operations on your type, which I'm not sure is such a good idea.

The real problem is that the syntax is overloaded. Somehow I don't
fancy the requirement to type NInteger 5 (respectively 5 :: Integer)
whenever I want to refer to 5 in an arithmetic expression, and
determining which constructor to apply automatically is the same
problem as the defaulting mechanism solves. (Only, with the algebraic
union, it must be solved at each and every numeric literal, rather
than the comparatively fewer times it would need to be solved in
general to make the system of type constraints determined.)

Ambiguity is actually seldom a real problem in practice. Usually
something comes along and fixes the type -- it's only really at the
GHCi/Hugs prompt that this is usually a major issue. This is another
reason perhaps why it hasn't been generalised. Probably the real
reason that it's restricted to Num is that instances of Num are the
only types with such overloaded syntax in the language. (I can write
5, and have it mean an Integer, Complex Double, a Rational, or a
constant power series of some type I cooked up.) There are other
situations where ambiguities can arise, but to be honest, I've never
been too annoyed by them.

Still, it sort of looks odd to have a feature which looks like it
could be vastly more general, but which only applies to this one
Prelude class Num, and only in contexts involving other Prelude
classes. Thinking about it more is making it clearer why it is
restricted to Num, though it's not obvious that it should remain that
way forever. The original question posed by Daniel is whether we
should lift the restriction that all of the classes involved are in a
standard library when doing defaulting. That's such a subtle and odd
point that there almost certainly is a reason for it. Does anyone know
it?

 - Cale