Program Compiles With GHC 6.6 but not Hat
The following program compiles and runs on GHC 6.6 but fails to compile with the '-hat' option to hmake. The error message is: **Begin Output** hat-trans HatTest.hs Wrote Hat/HatTest.hs ghc-6.6 -c -package hat -o Hat/HatTest.o Hat/HatTest.hs Hat/HatTest.hs:40:50: Ambiguous type variable `a' in the constraint: `Integral a' arising from use of `htakeodds' at Hat/HatTest.hs:40:50-58 Probable fix: add a type signature that fixes these type variable(s) **End Output** The program source is: import Prelude takeodds xs = [ x | x <- xs, (mod x 2) ==0] main = do { print (takeodds [1 ..7]); } Thanks... Deech _________________________________________________________________ Talk now to your Hotmail contacts with Windows Live Messenger. http://clk.atdmt.com/MSN/go/msnnkwme0020000001msn/direct/01/?href=http://get...
This is caused by a limitation of Hat: Hat cannot handle defaulting of numeric classes. Your Haskell program makes use of defaulting: The main function could work with numbers of either type Int or Integer. The Haskell defaulting rule says that in such a case it should choose Integer. To help Hat add a type annotation, e.g. main = do { print (takeodds [(1::Integer) ..7]); } To get a better error message, you could compile your original program without -hat but with the additonal line default() which turns defaulting off and thus will yield an error message about an ambiguous type variable referring to your original program. In real programs we have hardly ever come across uses of defaulting. Ciao, Olaf Aditya Siram wrote:
The following program compiles and runs on GHC 6.6 but fails to compile with the '-hat' option to hmake. The error message is: **Begin Output** hat-trans HatTest.hs Wrote Hat/HatTest.hs ghc-6.6 -c -package hat -o Hat/HatTest.o Hat/HatTest.hs
Hat/HatTest.hs:40:50: Ambiguous type variable `a' in the constraint: `Integral a' arising from use of `htakeodds' at Hat/HatTest.hs:40:50-58 Probable fix: add a type signature that fixes these type variable(s) **End Output**
The program source is:
import Prelude
takeodds xs = [ x | x <- xs, (mod x 2) ==0]
main = do { print (takeodds [1 ..7]); }
Thanks... Deech
_________________________________________________________________ Talk now to your Hotmail contacts with Windows Live Messenger. http://clk.atdmt.com/MSN/go/msnnkwme0020000001msn/direct/01/?href=http://get...
_______________________________________________ Hat mailing list Hat@haskell.org http://www.haskell.org/mailman/listinfo/hat
Olaf, This brings up something that's been niggling me for a while. Why can Hat not deal with defaulting? Surely it could be handled by the first stage of hat-trans being inserting explicit type signatures based on the standard defaulting rules? Bob On 17 Nov 2006, at 20:43, Olaf Chitil wrote:
This is caused by a limitation of Hat: Hat cannot handle defaulting of numeric classes.
Your Haskell program makes use of defaulting: The main function could work with numbers of either type Int or Integer. The Haskell defaulting rule says that in such a case it should choose Integer.
To help Hat add a type annotation, e.g.
main = do { print (takeodds [(1::Integer) ..7]); }
To get a better error message, you could compile your original program without -hat but with the additonal line
default()
which turns defaulting off and thus will yield an error message about an ambiguous type variable referring to your original program.
In real programs we have hardly ever come across uses of defaulting.
Ciao, Olaf
Aditya Siram wrote:
The following program compiles and runs on GHC 6.6 but fails to compile with the '-hat' option to hmake. The error message is: **Begin Output** hat-trans HatTest.hs Wrote Hat/HatTest.hs ghc-6.6 -c -package hat -o Hat/HatTest.o Hat/HatTest.hs
Hat/HatTest.hs:40:50: Ambiguous type variable `a' in the constraint: `Integral a' arising from use of `htakeodds' at Hat/HatTest.hs:40:50-58 Probable fix: add a type signature that fixes these type variable(s) **End Output**
The program source is:
import Prelude
takeodds xs = [ x | x <- xs, (mod x 2) ==0]
main = do { print (takeodds [1 ..7]); }
Thanks... Deech
_________________________________________________________________ Talk now to your Hotmail contacts with Windows Live Messenger. http://clk.atdmt.com/MSN/go/msnnkwme0020000001msn/direct/01/? href=http://get.live.com/messenger/overview
_______________________________________________ Hat mailing list Hat@haskell.org http://www.haskell.org/mailman/listinfo/hat
_______________________________________________ Hat mailing list Hat@haskell.org http://www.haskell.org/mailman/listinfo/hat
On 18/11/2006, at 11:14 AM, Thomas Davie wrote:
Olaf, This brings up something that's been niggling me for a while. Why can Hat not deal with defaulting? Surely it could be handled by the first stage of hat-trans being inserting explicit type signatures based on the standard defaulting rules?
Bob
That would require hat-trans to do type checking, wouldn't it? Bernie.
Hi
This brings up something that's been niggling me for a while. Why can Hat not deal with defaulting? Surely it could be handled by the first stage of hat-trans being inserting explicit type signatures based on the standard defaulting rules?
Bob
That would require hat-trans to do type checking, wouldn't it?
One idea that _might_ work is to translate Int -> Integer, then you get rid of defaulting integers, at the cost of changing the program semantics ever so slightly. Personally I'd say the cost is more than worth it, but I know some of the Hat developers disagree with me on that. Thanks Neil
On 19/11/2006, at 10:07 AM, Neil Mitchell wrote:
Hi
This brings up something that's been niggling me for a while. Why can Hat not deal with defaulting? Surely it could be handled by the first stage of hat-trans being inserting explicit type signatures based on the standard defaulting rules?
Bob
That would require hat-trans to do type checking, wouldn't it?
One idea that _might_ work is to translate Int -> Integer, then you get rid of defaulting integers, at the cost of changing the program semantics ever so slightly. Personally I'd say the cost is more than worth it, but I know some of the Hat developers disagree with me on that.
Thanks
Neil
Hi Neil, I would also argue strongly against that approach. It is important that debugging tools preserve the semantics of the underlying program as closely as possible. You might remove a slightly inconvenient problem, but at the cost of introducing subtle and difficult-to-explain changes in program behaviour. Probably the best solution is to lobby various compiler writers to generalise the defaulting mechanism, but that may be easier said than done :) Cheers, Bernie.
Hi Bernie,
I would also argue strongly against that approach.
It is important that debugging tools preserve the semantics of the underlying program as closely as possible.
Yes, but if the alternative is to make debugging so annoying that no one uses the debugging tool, then its probably a worthwhile trade off. Currently I don't use Hat, as when I am ready to debug a Haskell program (i.e. its broken) I can be pretty much 100% certain that it won't work with Hat without several changes. At the point I am trying to solve a complex bug, I don't want to go and do something else.
Probably the best solution is to lobby various compiler writers to generalise the defaulting mechanism, but that may be easier said than done :)
If you came up with a concrete proposal, that was a generalisation of the existing defaulting method, and provided an implementation for GHC, you might have a lot more success at your attempts. (Certainly if you implement in for Yhc, we'd accept it) Thanks Neil
Thomas Davie
This brings up something that's been niggling me for a while. Why can Hat not deal with defaulting? Surely it could be handled by the first stage of hat-trans being inserting explicit type signatures based on the standard defaulting rules?
We made a deliberate design decision that hat-trans should be entirely syntax-directed - it does not do type inference. There are good reasons for this decision. * In a well-designed language, you would not need type information for the tracing transformation. And indeed, Haskell is so well designed that you do not, except for this one very small (but very annoying) instance. * Implementing type inference is difficult enough that we did not consider the effort worthwhile for the tiny benefit of being able to handle defaulting. * In order to be able to handle all the many experimental type-system extensions accepted by a compiler like ghc, hat-trans would need to replicate ghc's type inference as exactly as possible. Given the number of papers written about this very topic, that would not be an easy task! But in fact, apart from defaulting, it is only necessary to _syntactically_ transform type signatures (where they are used), and the ghc type system can infer the rest. Regards, Malcolm
Hi
This brings up something that's been niggling me for a while. Why can Hat not deal with defaulting? Surely it could be handled by the first stage of hat-trans being inserting explicit type signatures based on the standard defaulting rules?
We made a deliberate design decision that hat-trans should be entirely syntax-directed - it does not do type inference. There are good reasons for this decision.
I have a plan to get round this :) Yhc currently generates Core, which is a nice abstract Haskell like language, close enough to the original to allow debugging in a reasonable similar environment. If Yhc.Core was converted to Hat traced Haskell then you'd get numeric defaulting for free. It's not perfect, but it might be worth it to get more reliable (but less accurate) Hat trace generation. I plan to do this sometime soon - its probably a few hours work at maximum. Thanks Neil
participants (6)
-
Aditya Siram -
Bernie Pope -
Malcolm Wallace -
Neil Mitchell -
Olaf Chitil -
Thomas Davie