"Neil Mitchell"
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