[Hat] Thoughts, Int vs Integer

[Malcolm Wallace]

"Neil Mitchell" <ndmitchell at gmail.com> wrote:

> Often when compiling with Hat I run into the Int vs Integer issue, in
> fact this is pretty much the biggest problem I have getting hat traces
> generated.

I think you are probably referring to the lack of defaulting for
ambiguous numeric literals.  This is not really an Int vs Integer
thing.  It occurs when an expression contains both numbers and numeric
operations without a type signature to disambiguate which specific type
to use for the operation.  In normal Haskell'98, they would default to
Integer.  There is no Int involved at all.  So your proposed solution
(aliasing Int to Integer) would not actually solve the problem, which
is about resolving class constraints.

> 1) big_number * 2 will never overflow, which will give a different
> semantics. Personally this sounds like a good idea, and having a
> hat-overflow tool to detect when an Integer goes above 2^31 would
> probably be a useful addition. I don't consider this change to be all
> that bad, since its compatible with the Haskell98 report (I think).

This kind of overflow detection would be somewhat easy to write in Tom's
proposed Hat query language (WHat).

    find an application of (*) [ or (+) ]
    where the absolute value of both operands exceeds 1
    where the absolute value of the result
      is smaller than the absolute value of either operand

    [ app | ((*) x y) <- app
          , absvalue(x) > 1
          , absvalue(y) > 1
          , (absvalue(app) < absvalue(x)) || (absvalue(app) < absvalue(y))
          ]

A similar property could also be written in QuickCheck, to find overflow
errors through testing.

> * Make all numeric literals 0 :: Integer

You could make a case for simply attaching a type signature to any
numeric literal that does not already have one.  It would certainly fix
the numeric defaulting problem, because it removes all ambiguity.

However, it would be incorrect for programs that do not currently suffer
from numeric ambiguity.  For instance, it is relatively common to define
new numeric types e.g. Matrix, where a literal number n has a reasonable
interpretation e.g. as the identity matrix scaled by n.  Forcing the
literal to be of type Integer would make the program type-incorrect.

Unfortunately, hat-trans is a syntactic transformation which
(deliberately) does not have access to type inference.  If it did, then
the defaulting problem would be easily solved.

Regards,
    Malcolm