3 ms·

stack repl with ghc 8.4.3 just gives me λ> import Data.Bits λ> let cube = [ [a `adj` b | b <- [0 .. 7] ] | a <- [0 .. 7] ] where a `adj` b = if (elem

stack repl with ghc 8.4.3 just gives me λ> import Data.Bits λ> let cube = [ [a `adj` b | b <- [0 .. 7] ] | a <- [0 .. 7] ] where a `adj` b = if (elem (xor a b) [1, 2, 4]) then 1 else 0 λ> :i cube cube :: Num a => [[a]] -- Defined at <interactive>:2:5 λ> cube [[0,1,1,0,1,0,0,0],[1,0,0,1,0,1,0,0],[1,0,0,1,0,0,1,0],[0,1,1,0,0,0,0,1],[1,0,0,0,0,1,1,0],[0,1,0,0,1,0,0,1],[0,0,1,0,1,0,0,1],[0,0,0,1,0,1,1,0]] same with ghc 7.10.3. Maybe I forgot to `import Data.Ring.Torsion`?

robinhouston 8y ago
Oddly[1] it seems to be different in the REPL. If I save this to cube.hs import Data.Bits a `adj` b = if (elem (xor a b) [1, 2, 4]) then 1 else 0 cube = [ [a `adj` b | b <- [0 .. 7] ] | a <- [0 .. 7] ] where a `adj` b = if (elem (xor a b) [1, 2, 4]) then 1 else 0 main = print $ cube and run ghc on it, I get a bunch of type errors: [1 of 1] Compiling Main ( /tmp/cube.hs, /tmp/cube.o ) /tmp/cube.hs:4:11: error: • Ambiguous type variable ‘a0’ arising from a use of ‘adj’ prevents the constraint ‘(Bits a0)’ from being solved. Relevant bindings include b :: a0 (bound at /tmp/cube.hs:4:23) a :: a0 (bound at /tmp/cube.hs:4:41) Probable fix: use a type annotation to specify what ‘a0’ should be. These potential instances exist: instance Bits Integer -- Defined in ‘Data.Bits’ instance Bits Bool -- Defined in ‘Data.Bits’ instance Bits Int -- Defined in ‘Data.Bits’ ...plus one other (use -fprint-potential-instances to see them all) • In the expression: a `adj` b In the expression: [a `adj` b | b <- [0 .. 7]] In the expression: [[a `adj` b | b <- [0 .. 7]] | a <- [0 .. 7]] /tmp/cube.hs:4:46: error: • Ambiguous type variable ‘a0’ arising from the arithmetic sequence ‘0 .. 7’ prevents the constraint ‘(Enum a0)’ from being solved. Probable fix: use a type annotation to specify what ‘a0’ should be. These potential instances exist: instance Enum Ordering -- Defined in ‘GHC.Enum’ instance Enum Integer -- Defined in ‘GHC.Enum’ instance Enum () -- Defined in ‘GHC.Enum’ ...plus six others ...plus six instances involving out-of-scope types (use -fprint-potential-instances to see them all) • In the expression: [0 .. 7] In a stmt of a list comprehension: a <- [0 .. 7] In the expression: [[a `adj` b | b <- [0 .. 7]] | a <- [0 .. 7]] /tmp/cube.hs:4:47: error: • Ambiguous type variable ‘a0’ arising from the literal ‘0’ prevents the constraint ‘(Num a0)’ from being solved. Probable fix: use a type annotation to specify what ‘a0’ should be. These potential instances exist: instance Num Integer -- Defined in ‘GHC.Num’ instance Num Double -- Defined in ‘GHC.Float’ instance Num Float -- Defined in ‘GHC.Float’ ...plus two others ...plus three instances involving out-of-scope types (use -fprint-potential-instances to see them all) • In the expression: 0 In the expression: [0 .. 7] In a stmt of a list comprehension: a <- [0 .. 7] This is with GHC 8.0.1. Adding :: Integer after the 0 makes it compile and run correctly. 1. This is probably not odd if you know more about GHC than I do.
- quickthrower2 8y ago
  I think that the rant piece is out of proportion to the problem. Which other languages give you the ability to omit type definitions and have them inferred at compile time?* And this one time it doesn't figure it out and you need to specify Int. The biggest problem is the error message. Error messages being unhelpful to beginners is a big problem in general, e.g. see JavaScript. But GHC errors are also scary looking! *Except for Haskell inspired languages and typescript, but typescript suffers from it's strength as JS compatible.

robinhouston 8y ago

Oddly[1] it seems to be different in the REPL. If I save this to cube.hs import Data.Bits a `adj` b = if (elem (xor a b) [1, 2, 4]) then 1 else 0 cube = [ [a `adj` b | b <- [0 .. 7] ] | a <- [0 .. 7] ] where a `adj` b = if (elem (xor a b) [1, 2, 4]) then 1 else 0 main = print $ cube and run ghc on it, I get a bunch of type errors: [1 of 1] Compiling Main ( /tmp/cube.hs, /tmp/cube.o ) /tmp/cube.hs:4:11: error: • Ambiguous type variable ‘a0’ arising from a use of ‘adj’ prevents the constraint ‘(Bits a0)’ from being solved. Relevant bindings include b :: a0 (bound at /tmp/cube.hs:4:23) a :: a0 (bound at /tmp/cube.hs:4:41) Probable fix: use a type annotation to specify what ‘a0’ should be. These potential instances exist: instance Bits Integer -- Defined in ‘Data.Bits’ instance Bits Bool -- Defined in ‘Data.Bits’ instance Bits Int -- Defined in ‘Data.Bits’ ...plus one other (use -fprint-potential-instances to see them all) • In the expression: a `adj` b In the expression: [a `adj` b | b <- [0 .. 7]] In the expression: [[a `adj` b | b <- [0 .. 7]] | a <- [0 .. 7]] /tmp/cube.hs:4:46: error: • Ambiguous type variable ‘a0’ arising from the arithmetic sequence ‘0 .. 7’ prevents the constraint ‘(Enum a0)’ from being solved. Probable fix: use a type annotation to specify what ‘a0’ should be. These potential instances exist: instance Enum Ordering -- Defined in ‘GHC.Enum’ instance Enum Integer -- Defined in ‘GHC.Enum’ instance Enum () -- Defined in ‘GHC.Enum’ ...plus six others ...plus six instances involving out-of-scope types (use -fprint-potential-instances to see them all) • In the expression: [0 .. 7] In a stmt of a list comprehension: a <- [0 .. 7] In the expression: [[a `adj` b | b <- [0 .. 7]] | a <- [0 .. 7]] /tmp/cube.hs:4:47: error: • Ambiguous type variable ‘a0’ arising from the literal ‘0’ prevents the constraint ‘(Num a0)’ from being solved. Probable fix: use a type annotation to specify what ‘a0’ should be. These potential instances exist: instance Num Integer -- Defined in ‘GHC.Num’ instance Num Double -- Defined in ‘GHC.Float’ instance Num Float -- Defined in ‘GHC.Float’ ...plus two others ...plus three instances involving out-of-scope types (use -fprint-potential-instances to see them all) • In the expression: 0 In the expression: [0 .. 7] In a stmt of a list comprehension: a <- [0 .. 7] This is with GHC 8.0.1. Adding :: Integer after the 0 makes it compile and run correctly. 1. This is probably not odd if you know more about GHC than I do.

quickthrower2 8y ago
I think that the rant piece is out of proportion to the problem. Which other languages give you the ability to omit type definitions and have them inferred at compile time?* And this one time it doesn't figure it out and you need to specify Int. The biggest problem is the error message. Error messages being unhelpful to beginners is a big problem in general, e.g. see JavaScript. But GHC errors are also scary looking! *Except for Haskell inspired languages and typescript, but typescript suffers from it's strength as JS compatible.