g x = [2] ++ [3,5..truncate(sqrt x)] p n = fp n (g n) fp n [ ] = True fp n (x:xs) = if (mod n x) == 0 then False else fp n xs
ERROR - Unresolved overloading *** Type : (RealFrac a, Floating a, Integral a) => Bool *** Expression : p 103
I know why, there is no type that is at the same time: RealFrac, Floating and Integral; but I don´t know how to solve. What kind of type casting or type definition can I use to fix the error?
this can be turned into a nice small example for many things are a right, and many things that are wrong with haskell numeric programs (cf. http://www.haskell.org/haskellwiki/Generic_numeric_type ). not only are the typical type errors confusing, and give little help with fixing the issue (deliberately highlighting unresolved choices rather than choosing arbitrary defaults, but not even suggesting possible conversions with pros and cons [*]), but placating the type system in various ways is not sufficient to guarantee useability, or intended results, and seemingly simple rewrites may require type system extensions to remain simple. first, note that the definitions typecheck even though it would be difficult to find a correct way of using them. next, consider the variations appended below (using different conversions, or breaking the strong connection introduced by the lambda- bound 'n' in the original 'p0'). again, this typechecks, and can indeed be used, but that is no guarantee that the variants are equivalent, or do what was intended, or even work for other use cases. for fun, try changing '103' to '103.5' (and no, you can't abstract that to a where-clause unless you rely on 'no-monomorphism-restriction'), then comment out the lines in main that start raising errors one by one, then run the remaining lines and enjoy the result. then consider whether this is indeed an intended use case. i'm all for safe, explicit coercions rather than unsafe defaults. but typechecking definitions is not sufficient to guarantee either useability or correctness here, and type errors give little help in clarifying intentions and correcting code. in other words, there is something wrong in this part of haskell, even below the concerns that usually lead to alternative numerical preludes. i'm not at all sure to what extent this can be improved, but when the topic comes up, good examples are usually hard to come by, so i just wanted to record this one here for the mailing-list archives. claus [*] sometimes i wonder whether there should be a WrongNum type, which would imply all the usual default conversions of scripting languages, but would generate warnings at each dubious usage site (about comparing Doubles, or losing precision, or possible overflows, ..). that way, beginners might at least get something running that they could then improve until the warnings are gone, avoiding the blank-page effect. instead of saying "i have no idea what to do here", the system would say "i'm defaulting to Double here, but that might not be a good idea, so please confirm this decision explicitly in the code", or "i'm applying this implicit conversion here, but this has semantic consequences, so you probably want to choose this or a related conversion explicitly in your code".. ---------------------------------------------- code variations {-# OPTIONS_GHC -fno-monomorphism-restriction #-} {-# OPTIONS_GHC -fglasgow-exts #-} g x = [2] ++ [3,5..truncate(sqrt x)] p0 n = fp n (g n) p1a n = fp (truncate n) (g n) p1b n = fp (round n) (g n) p1c n = fp n (g $ fromIntegral n) p2 n n' = fp n (g n') p3 :: (forall a. Num a => a) -> Bool p3 n = fp n (g n) fp n [ ] = True fp n (x:xs) = if (mod n x) == 0 then False else fp n xs main = do -- print $ p0 103 -- original, with type error print $ p1a 103 print $ p1b 103 print $ p1c 103 print $ p2 103 103 print $ let x = 103 in p2 x x -- requires no-monomorphism-restriction print $ let x _ = 103 in p2 (x ()) (x ()) print $ p3 103 -- requires glasgow-exts