Re: Unexpected ambiguity in a seemingly valid Haskell 2010 program
Apparently not — the code comilers with any of -XNoMonoLocalBinds and -XMonoLocalBinds, but not with -XNoMonomorphismRestriction. * wagne...@seas.upenn.edu wagne...@seas.upenn.edu [2012-11-09 14:07:59-0500] It's possible that the below blog post is related. ~d http://hackage.haskell.org/trac/ghc/blog/LetGeneralisationInGhc7 Quoting Roman Cheplyaka r...@ro-che.info: For this module module Test where import System.Random data RPS = Rock | Paper | Scissors deriving (Show, Enum) instance Random RPS where random g = let (x, g') = randomR (0, 2) g in (toEnum x, g') randomR = undefined ghc (7.4.1 and 7.6.1) reports an error: rand.hs:9:9: No instance for (Random t0) arising from the ambiguity check for g' The type variable `t0' is ambiguous Possible fix: add a type signature that fixes these type variable(s) Note: there are several potential instances: instance Random RPS -- Defined at rand.hs:7:10 instance Random Bool -- Defined in `System.Random' instance Random Foreign.C.Types.CChar -- Defined in `System.Random' ...plus 34 others When checking that g' has the inferred type `g' Probable cause: the inferred type is ambiguous In the expression: let (x, g') = randomR (0, 2) g in (toEnum x, g') In an equation for `random': random g = let (x, g') = randomR ... g in (toEnum x, g') Failed, modules loaded: none. There should be no ambiguity since 'toEnum' determines the type of x (Int), and that in turn fixes types of 0 and 2. Interestingly, annotating 0 or 2 with the type makes the problem go away. jhc 0.8.0 compiles this module fine. Roman ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Unexpected ambiguity in a seemingly valid Haskell 2010 program
That's strange. Here, it only fails with both NoMonomorphismRestriction and NoMonoLocalBinds (which makes sense). I've tested on 7.4.1 and 7.6.1. Erik On Sun, Nov 11, 2012 at 3:54 PM, Roman Cheplyaka r...@ro-che.info wrote: Apparently not — the code comilers with any of -XNoMonoLocalBinds and -XMonoLocalBinds, but not with -XNoMonomorphismRestriction. * wagne...@seas.upenn.edu wagne...@seas.upenn.edu [2012-11-09 14:07:59-0500] It's possible that the below blog post is related. ~d http://hackage.haskell.org/trac/ghc/blog/LetGeneralisationInGhc7 Quoting Roman Cheplyaka r...@ro-che.info: For this module module Test where import System.Random data RPS = Rock | Paper | Scissors deriving (Show, Enum) instance Random RPS where random g = let (x, g') = randomR (0, 2) g in (toEnum x, g') randomR = undefined ghc (7.4.1 and 7.6.1) reports an error: rand.hs:9:9: No instance for (Random t0) arising from the ambiguity check for g' The type variable `t0' is ambiguous Possible fix: add a type signature that fixes these type variable(s) Note: there are several potential instances: instance Random RPS -- Defined at rand.hs:7:10 instance Random Bool -- Defined in `System.Random' instance Random Foreign.C.Types.CChar -- Defined in `System.Random' ...plus 34 others When checking that g' has the inferred type `g' Probable cause: the inferred type is ambiguous In the expression: let (x, g') = randomR (0, 2) g in (toEnum x, g') In an equation for `random': random g = let (x, g') = randomR ... g in (toEnum x, g') Failed, modules loaded: none. There should be no ambiguity since 'toEnum' determines the type of x (Int), and that in turn fixes types of 0 and 2. Interestingly, annotating 0 or 2 with the type makes the problem go away. jhc 0.8.0 compiles this module fine. Roman ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Unexpected ambiguity in a seemingly valid Haskell 2010 program
Right. What I meant is that with -XMonomorphismRestriction, it compiles with with both -XMonoLocalBinds and -XNoMonoLocalBinds. That means that MonoLocalBinds can not be solely responsible for this behaviour. Anyway, I just noticed that a very similar example (using Read) is described in the Haskell report's section on the monomorphism restriction. Roman * Erik Hesselink hessel...@gmail.com [2012-11-11 16:43:20+0100] That's strange. Here, it only fails with both NoMonomorphismRestriction and NoMonoLocalBinds (which makes sense). I've tested on 7.4.1 and 7.6.1. Erik On Sun, Nov 11, 2012 at 3:54 PM, Roman Cheplyaka r...@ro-che.info wrote: Apparently not — the code comilers with any of -XNoMonoLocalBinds and -XMonoLocalBinds, but not with -XNoMonomorphismRestriction. * wagne...@seas.upenn.edu wagne...@seas.upenn.edu [2012-11-09 14:07:59-0500] It's possible that the below blog post is related. ~d http://hackage.haskell.org/trac/ghc/blog/LetGeneralisationInGhc7 Quoting Roman Cheplyaka r...@ro-che.info: For this module module Test where import System.Random data RPS = Rock | Paper | Scissors deriving (Show, Enum) instance Random RPS where random g = let (x, g') = randomR (0, 2) g in (toEnum x, g') randomR = undefined ghc (7.4.1 and 7.6.1) reports an error: rand.hs:9:9: No instance for (Random t0) arising from the ambiguity check for g' The type variable `t0' is ambiguous Possible fix: add a type signature that fixes these type variable(s) Note: there are several potential instances: instance Random RPS -- Defined at rand.hs:7:10 instance Random Bool -- Defined in `System.Random' instance Random Foreign.C.Types.CChar -- Defined in `System.Random' ...plus 34 others When checking that g' has the inferred type `g' Probable cause: the inferred type is ambiguous In the expression: let (x, g') = randomR (0, 2) g in (toEnum x, g') In an equation for `random': random g = let (x, g') = randomR ... g in (toEnum x, g') Failed, modules loaded: none. There should be no ambiguity since 'toEnum' determines the type of x (Int), and that in turn fixes types of 0 and 2. Interestingly, annotating 0 or 2 with the type makes the problem go away. jhc 0.8.0 compiles this module fine. Roman ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Unexpected ambiguity in a seemingly valid Haskell 2010 program
That makes sense: MonomorphismRestriction makes bindings without parameters monomorphic, and MonoLocalBinds makes local bindings monomorphic. So either one will make this binding monomorphic. Only when both are off does it become polymorphic and does the error occur. Erik On Sun, Nov 11, 2012 at 5:37 PM, Roman Cheplyaka r...@ro-che.info wrote: Right. What I meant is that with -XMonomorphismRestriction, it compiles with with both -XMonoLocalBinds and -XNoMonoLocalBinds. That means that MonoLocalBinds can not be solely responsible for this behaviour. Anyway, I just noticed that a very similar example (using Read) is described in the Haskell report's section on the monomorphism restriction. Roman * Erik Hesselink hessel...@gmail.com [2012-11-11 16:43:20+0100] That's strange. Here, it only fails with both NoMonomorphismRestriction and NoMonoLocalBinds (which makes sense). I've tested on 7.4.1 and 7.6.1. Erik On Sun, Nov 11, 2012 at 3:54 PM, Roman Cheplyaka r...@ro-che.info wrote: Apparently not — the code comilers with any of -XNoMonoLocalBinds and -XMonoLocalBinds, but not with -XNoMonomorphismRestriction. * wagne...@seas.upenn.edu wagne...@seas.upenn.edu [2012-11-09 14:07:59-0500] It's possible that the below blog post is related. ~d http://hackage.haskell.org/trac/ghc/blog/LetGeneralisationInGhc7 Quoting Roman Cheplyaka r...@ro-che.info: For this module module Test where import System.Random data RPS = Rock | Paper | Scissors deriving (Show, Enum) instance Random RPS where random g = let (x, g') = randomR (0, 2) g in (toEnum x, g') randomR = undefined ghc (7.4.1 and 7.6.1) reports an error: rand.hs:9:9: No instance for (Random t0) arising from the ambiguity check for g' The type variable `t0' is ambiguous Possible fix: add a type signature that fixes these type variable(s) Note: there are several potential instances: instance Random RPS -- Defined at rand.hs:7:10 instance Random Bool -- Defined in `System.Random' instance Random Foreign.C.Types.CChar -- Defined in `System.Random' ...plus 34 others When checking that g' has the inferred type `g' Probable cause: the inferred type is ambiguous In the expression: let (x, g') = randomR (0, 2) g in (toEnum x, g') In an equation for `random': random g = let (x, g') = randomR ... g in (toEnum x, g') Failed, modules loaded: none. There should be no ambiguity since 'toEnum' determines the type of x (Int), and that in turn fixes types of 0 and 2. Interestingly, annotating 0 or 2 with the type makes the problem go away. jhc 0.8.0 compiles this module fine. Roman ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Unexpected ambiguity in a seemingly valid Haskell 2010 program
For this module module Test where import System.Random data RPS = Rock | Paper | Scissors deriving (Show, Enum) instance Random RPS where random g = let (x, g') = randomR (0, 2) g in (toEnum x, g') randomR = undefined ghc (7.4.1 and 7.6.1) reports an error: rand.hs:9:9: No instance for (Random t0) arising from the ambiguity check for g' The type variable `t0' is ambiguous Possible fix: add a type signature that fixes these type variable(s) Note: there are several potential instances: instance Random RPS -- Defined at rand.hs:7:10 instance Random Bool -- Defined in `System.Random' instance Random Foreign.C.Types.CChar -- Defined in `System.Random' ...plus 34 others When checking that g' has the inferred type `g' Probable cause: the inferred type is ambiguous In the expression: let (x, g') = randomR (0, 2) g in (toEnum x, g') In an equation for `random': random g = let (x, g') = randomR ... g in (toEnum x, g') Failed, modules loaded: none. There should be no ambiguity since 'toEnum' determines the type of x (Int), and that in turn fixes types of 0 and 2. Interestingly, annotating 0 or 2 with the type makes the problem go away. jhc 0.8.0 compiles this module fine. Roman ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Unexpected ambiguity in a seemingly valid Haskell 2010 program
My GHC 7.6.1 (on a Mac) compiles this code without any warnings or errors. Do you have some other compilation flags in effect? On Fri, Nov 9, 2012 at 11:09 AM, Roman Cheplyaka r...@ro-che.info wrote: For this module module Test where import System.Random data RPS = Rock | Paper | Scissors deriving (Show, Enum) instance Random RPS where random g = let (x, g') = randomR (0, 2) g in (toEnum x, g') randomR = undefined ghc (7.4.1 and 7.6.1) reports an error: rand.hs:9:9: No instance for (Random t0) arising from the ambiguity check for g' The type variable `t0' is ambiguous Possible fix: add a type signature that fixes these type variable(s) Note: there are several potential instances: instance Random RPS -- Defined at rand.hs:7:10 instance Random Bool -- Defined in `System.Random' instance Random Foreign.C.Types.CChar -- Defined in `System.Random' ...plus 34 others When checking that g' has the inferred type `g' Probable cause: the inferred type is ambiguous In the expression: let (x, g') = randomR (0, 2) g in (toEnum x, g') In an equation for `random': random g = let (x, g') = randomR ... g in (toEnum x, g') Failed, modules loaded: none. There should be no ambiguity since 'toEnum' determines the type of x (Int), and that in turn fixes types of 0 and 2. Interestingly, annotating 0 or 2 with the type makes the problem go away. jhc 0.8.0 compiles this module fine. Roman ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Unexpected ambiguity in a seemingly valid Haskell 2010 program
Oops, you are right — I had -XNoMonomorphismRestriction in .ghci. I'm not sure whether this fact makes the situation more or less strange :) Roman * Nicolas Frisby nicolas.fri...@gmail.com [2012-11-09 11:35:58-0600] My GHC 7.6.1 (on a Mac) compiles this code without any warnings or errors. Do you have some other compilation flags in effect? On Fri, Nov 9, 2012 at 11:09 AM, Roman Cheplyaka r...@ro-che.info wrote: For this module module Test where import System.Random data RPS = Rock | Paper | Scissors deriving (Show, Enum) instance Random RPS where random g = let (x, g') = randomR (0, 2) g in (toEnum x, g') randomR = undefined ghc (7.4.1 and 7.6.1) reports an error: rand.hs:9:9: No instance for (Random t0) arising from the ambiguity check for g' The type variable `t0' is ambiguous Possible fix: add a type signature that fixes these type variable(s) Note: there are several potential instances: instance Random RPS -- Defined at rand.hs:7:10 instance Random Bool -- Defined in `System.Random' instance Random Foreign.C.Types.CChar -- Defined in `System.Random' ...plus 34 others When checking that g' has the inferred type `g' Probable cause: the inferred type is ambiguous In the expression: let (x, g') = randomR (0, 2) g in (toEnum x, g') In an equation for `random': random g = let (x, g') = randomR ... g in (toEnum x, g') Failed, modules loaded: none. There should be no ambiguity since 'toEnum' determines the type of x (Int), and that in turn fixes types of 0 and 2. Interestingly, annotating 0 or 2 with the type makes the problem go away. jhc 0.8.0 compiles this module fine. Roman ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Unexpected ambiguity in a seemingly valid Haskell 2010 program
It's possible that the below blog post is related. ~d http://hackage.haskell.org/trac/ghc/blog/LetGeneralisationInGhc7 Quoting Roman Cheplyaka r...@ro-che.info: For this module module Test where import System.Random data RPS = Rock | Paper | Scissors deriving (Show, Enum) instance Random RPS where random g = let (x, g') = randomR (0, 2) g in (toEnum x, g') randomR = undefined ghc (7.4.1 and 7.6.1) reports an error: rand.hs:9:9: No instance for (Random t0) arising from the ambiguity check for g' The type variable `t0' is ambiguous Possible fix: add a type signature that fixes these type variable(s) Note: there are several potential instances: instance Random RPS -- Defined at rand.hs:7:10 instance Random Bool -- Defined in `System.Random' instance Random Foreign.C.Types.CChar -- Defined in `System.Random' ...plus 34 others When checking that g' has the inferred type `g' Probable cause: the inferred type is ambiguous In the expression: let (x, g') = randomR (0, 2) g in (toEnum x, g') In an equation for `random': random g = let (x, g') = randomR ... g in (toEnum x, g') Failed, modules loaded: none. There should be no ambiguity since 'toEnum' determines the type of x (Int), and that in turn fixes types of 0 and 2. Interestingly, annotating 0 or 2 with the type makes the problem go away. jhc 0.8.0 compiles this module fine. Roman ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
unexpected ambiguity
Hello, Trying to compile the attached modules gives the following error message: Main.hs:8:15: Ambiguous occurrence `lift' It could refer to either `Control.Monad.Trans.lift', ... or `Apa.lift', imported from Apa at ... Is this correct? I would have expected that an unqualified lift could only refer to the one exported from Apa in this case. /Niklas module Apa where lift = id module Main where import Control.Monad.State import qualified Control.Monad.Trans as T ( lift ) import Apa as A apa :: IO a - StateT () IO a apa = T.lift . lift ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: unexpected ambiguity
Niklas Sorensson wrote: Main.hs:8:15: Ambiguous occurrence `lift' It could refer to either `Control.Monad.Trans.lift', ... or `Apa.lift', imported from Apa at ... Is this correct? I would have expected that an unqualified lift could only refer to the one exported from Apa in this case. The error is correct. The module Control.Monad.State re-export the lift identifier from Control.Monad.Trans. Thus the line 'import Control.Monad.State' is the evildoer. Use for example: import Control.Monad.State hiding (lift) The error message surly makes you look in the wrong direction. Cheers, Christof ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: unexpected ambiguity
[EMAIL PROTECTED] wrote: Niklas Sorensson wrote: Main.hs:8:15: Ambiguous occurrence `lift' It could refer to either `Control.Monad.Trans.lift', ... or `Apa.lift', imported from Apa at ... Is this correct? I would have expected that an unqualified lift could only refer to the one exported from Apa in this case. The error is correct. The module Control.Monad.State re-export the lift identifier from Control.Monad.Trans. Thus the line 'import Control.Monad.State' is the evildoer. Use for example: import Control.Monad.State hiding (lift) The error message surly makes you look in the wrong direction. Ideed. Thanks for the explanation! /Niklas ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
