GHC doesn't like its own type?
The previously message "Deeply uncurried products, as categorists might like them" can be used to demonstrate certain behavior of GHC that seems a bit odd. If we save the text of that message in a file, /tmp/a.lhs, we can load it into GHC: $ ghci -fglasgow-exts /tmp/a.lhs GHC Interactive, version 5.04.1 Ok, modules loaded: Main. *Main> The whole code loads and typechecks. The code contains the following definition, without an explicit type signature:
fcomp a = (. fapp) (mcomp a)
We can ask GHCi to tell us the type of fcomp: *Main> :type fcomp forall result f1 a f2 c cp. (FApp a cp c, MCompose f2 cp c result) => (f1 -> f2) -> a -> f1 -> result and make that type, verbatim, to be the signature of fcomp:
fcomp:: forall result f1 a f2 c cp. (FApp a cp c, MCompose f2 cp c result) => (f1 -> f2) -> a -> f1 -> result fcomp a = (. fapp) (mcomp a)
If we reload the file, we get an error: /tmp/a.lhs:124: Could not deduce (FApp a cp c1) from the context (FApp a cp c, MCompose f2 cp c result) Probable fix: Add (FApp a cp c1) to the type signature(s) for `fcomp' arising from use of `fapp' at /tmp/a.lhs:124 In the second argument of `(.)', namely `fapp' In the definition of `fcomp': (. fapp) (mcomp a) /tmp/a.lhs:124: Could not deduce (MCompose f2 cp c1 result) from the context (FApp a cp c, MCompose f2 cp c result) Probable fix: Add (MCompose f2 cp c1 result) to the type signature(s) for `fcomp' arising from use of `mcomp' at /tmp/a.lhs:124 In the first argument of `(. fapp)', namely `(mcomp a)' In the definition of `fcomp': (. fapp) (mcomp a) I used to think that the inferred type is the most general type, and that the compiler would accept as explicit the type that it itself inferred. I was wrong? The second odd circumstance is best illustrated by the following transcript. Assume that /tmp/a.lhs is the text of the previous message as it was posted: $ ghci -fglasgow-exts /tmp/a.lhs GHC Interactive, version 5.04.1, for Haskell 98. Loading package base ... linking ... done. Loading package haskell98 ... linking ... done. Compiling Main ( /tmp/a.lhs, interpreted ) /tmp/a.lhs:76: Warning: No 'main' defined in module Main Ok, modules loaded: Main. *Main> let x = \f -> fapp f (('a','b'),('c',('d','e'))) Bus error (core dumped) Incidentally, if I enter
x = \f -> fapp f (('a','b'),('c',('d','e'))) into /tmp/a.lhs and load the file into GHCi, I get
ghc-5.04.1: panic! (the `impossible' happened, GHC version 5.04.1): rdrNameModule zddFApp
hi, i remeber some time ago levent erkok run intro a simillar problem. take a look at this post: http://www.mail-archive.com/haskell@haskell.org/msg06754.html i think the problem is that when you add a type signature things may become more polymorphic, but i am not sure if this is what you are running into. as your second point illustrates, there also seems to be a bug in ghc. bye iavor oleg@pobox.com wrote:
The previously message "Deeply uncurried products, as categorists might like them" can be used to demonstrate certain behavior of GHC that seems a bit odd. If we save the text of that message in a file, /tmp/a.lhs, we can load it into GHC:
$ ghci -fglasgow-exts /tmp/a.lhs GHC Interactive, version 5.04.1 Ok, modules loaded: Main. *Main>
The whole code loads and typechecks. The code contains the following definition, without an explicit type signature:
fcomp a = (. fapp) (mcomp a)
We can ask GHCi to tell us the type of fcomp:
*Main> :type fcomp forall result f1 a f2 c cp. (FApp a cp c, MCompose f2 cp c result) => (f1 -> f2) -> a -> f1 -> result
and make that type, verbatim, to be the signature of fcomp:
fcomp:: forall result f1 a f2 c cp. (FApp a cp c, MCompose f2 cp c result) => (f1 -> f2) -> a -> f1 -> result fcomp a = (. fapp) (mcomp a)
If we reload the file, we get an error:
/tmp/a.lhs:124: Could not deduce (FApp a cp c1) from the context (FApp a cp c, MCompose f2 cp c result) Probable fix: Add (FApp a cp c1) to the type signature(s) for `fcomp' arising from use of `fapp' at /tmp/a.lhs:124 In the second argument of `(.)', namely `fapp' In the definition of `fcomp': (. fapp) (mcomp a)
/tmp/a.lhs:124: Could not deduce (MCompose f2 cp c1 result) from the context (FApp a cp c, MCompose f2 cp c result) Probable fix: Add (MCompose f2 cp c1 result) to the type signature(s) for `fcomp' arising from use of `mcomp' at /tmp/a.lhs:124 In the first argument of `(. fapp)', namely `(mcomp a)' In the definition of `fcomp': (. fapp) (mcomp a)
I used to think that the inferred type is the most general type, and that the compiler would accept as explicit the type that it itself inferred. I was wrong?
The second odd circumstance is best illustrated by the following transcript. Assume that /tmp/a.lhs is the text of the previous message as it was posted:
$ ghci -fglasgow-exts /tmp/a.lhs GHC Interactive, version 5.04.1, for Haskell 98. Loading package base ... linking ... done. Loading package haskell98 ... linking ... done. Compiling Main ( /tmp/a.lhs, interpreted )
/tmp/a.lhs:76: Warning: No 'main' defined in module Main Ok, modules loaded: Main. *Main> let x = \f -> fapp f (('a','b'),('c',('d','e'))) Bus error (core dumped)
Incidentally, if I enter
x = \f -> fapp f (('a','b'),('c',('d','e')))
into /tmp/a.lhs and load the file into GHCi, I get
ghc-5.04.1: panic! (the `impossible' happened, GHC version 5.04.1): rdrNameModule zddFApp _______________________________________________ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
The second odd circumstance is best illustrated by the following transcript. Assume that /tmp/a.lhs is the text of the previous message as it was posted:
$ ghci -fglasgow-exts /tmp/a.lhs GHC Interactive, version 5.04.1, for Haskell 98. Loading package base ... linking ... done. Loading package haskell98 ... linking ... done. Compiling Main ( /tmp/a.lhs, interpreted )
/tmp/a.lhs:76: Warning: No 'main' defined in module Main Ok, modules loaded: Main. *Main> let x = \f -> fapp f (('a','b'),('c',('d','e'))) Bus error (core dumped)
Incidentally, if I enter
x = \f -> fapp f (('a','b'),('c',('d','e'))) into /tmp/a.lhs and load the file into GHCi, I get
ghc-5.04.1: panic! (the `impossible' happened, GHC version 5.04.1): rdrNameModule zddFApp
These are both instances of the same bug, which Simon P.J. fixed a couple of months ago. Unfortunately the fix isn't in the latest 5.04.3 release, but it will be in the next major release. Cheers, Simon
participants (3)
-
Iavor Diatchki -
oleg＠pobox.com -
Simon Marlow