http://www.cse.unsw.edu.au/~dons/code/nobench/real/compress/compress.hs if you notice this program has the line
compress = map toEnum . codes_to_ascii . encode
It seems to me this should run afoul of the monomorphism restriction due to the unknown ambiguous type in Enum, but ghc 6.8.2 happily accepts it. Jhc thinks it is illegal according to my reading of the specification. Any ideas about what is going on here? John -- John Meacham - ⑆repetae.net⑆john⑈
No, it's fine. compress is indeed monomorphic, but since it's called at exactly one type, namely Char, so it gets the monomorphic type [Char] -> [Char]. That is what the Haskell Report says. (Or tries to.) Simon | -----Original Message----- | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell-users-bounces@haskell.org] On Behalf Of | John Meacham | Sent: 06 March 2008 07:26 | To: glasgow-haskell-users@haskell.org | Subject: monomorphic or not? | | http://www.cse.unsw.edu.au/~dons/code/nobench/real/compress/compress.hs | | if you notice this program has the line | | > compress = map toEnum . codes_to_ascii . encode | | It seems to me this should run afoul of the monomorphism restriction due | to the unknown ambiguous type in Enum, but ghc 6.8.2 happily accepts it. | Jhc thinks it is illegal according to my reading of the specification. | Any ideas about what is going on here? | | John | | -- | John Meacham - ⑆repetae.net⑆john⑈ | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
On Thu, Mar 06, 2008 at 08:56:15AM +0000, Simon Peyton-Jones wrote:
No, it's fine. compress is indeed monomorphic, but since it's called at exactly one type, namely Char, so it gets the monomorphic type [Char] -> [Char]. That is what the Haskell Report says. (Or tries to.)
But when I modify the module header to be:
module Main(main,compress) where
It still doesn't complain, it can't know that all other uses of 'compress' in other modules will also be at a Char type. It also seems to me that the Dependency Analysis (4.5.1 in the report) would cause 'compress' to be typed and generalized before 'main' was even processed... Hmm.. John -- John Meacham - ⑆repetae.net⑆john⑈
| On Thu, Mar 06, 2008 at 08:56:15AM +0000, Simon Peyton-Jones wrote: | > No, it's fine. compress is indeed monomorphic, but since it's called | > at exactly one type, namely Char, so it gets the monomorphic type | > [Char] -> [Char]. That is what the Haskell Report says. (Or tries | > to.) | | But when I modify the module header to be: | | > module Main(main,compress) where | | It still doesn't complain, it can't know that all other uses of | 'compress' in other modules will also be at a Char type. See 4.5.5 in the Report http://haskell.org/onlinereport/decls.html. Rule 1 says that 'compress' is not generalised. So it gets the type [t] -> [t] where 'a' is an as-yet-un-determined type; in implementation terms, a unification variable. Rule 2 says "Any monomorphic type variables that remain when type inference for an entire module is complete, are considered ambiguous, and are resolved to particular types using the defaulting rules". But in this case no monomoprhic variables remain, because by then the type of compress has been refined to [Char] -> [Char] Well, that's the way GHC interprets the report anyway! Simon
On Thu, Mar 06, 2008 at 11:43:08AM +0000, Simon Peyton-Jones wrote:
See 4.5.5 in the Report http://haskell.org/onlinereport/decls.html.
Rule 1 says that 'compress' is not generalised. So it gets the type [t] -> [t] where 'a' is an as-yet-un-determined type; in implementation terms, a unification variable.
Rule 2 says "Any monomorphic type variables that remain when type inference for an entire module is complete, are considered ambiguous, and are resolved to particular types using the defaulting rules". But in this case no monomoprhic variables remain, because by then the type of compress has been refined to [Char] -> [Char]
Ah! it all makes sense now. excellent. It has been a persistent annoyance that jhc gets dinged by the monomorphism restriction more than ghc, but now I see why. thanks! John -- John Meacham - ⑆repetae.net⑆john⑈
participants (2)
-
John Meacham -
Simon Peyton-Jones