Could not deduce (Num [Char]) arising from the literal - haskell

Question

guys, i just started learning haskell (and to code) and i have ran into a problem that i can't figure out. So there is this exercise in which i have to present the number of solutions for a 2nd degree equation.
valid a b c = if [a,b,c] == [0,0,0] then False
else (if [a,b] == [0,0] then False
else (if a == 0 then False
else True)) --function to make sure it is a 2nd degree eq
nRaizes a b c = if valid a b c == False then "not a valid eq"
else (if (b^2 - 4 * a * c) > 0 then 2
else (if ((b^2 - 4 * a * c) == 0) then 1
else 0))
Everything looked fine to me, but when i try to load the script in GHCI i get the error message:
Could not deduce (Num [Char]) arising from the literal ‘2’
from the context (Num a, Ord a)
bound by the inferred type of
nRaizes :: (Num a, Ord a) => a -> a -> a -> [Char]
at ficha1.hs:(18,1)-(21,13)
In the expression: 2
In the expression:
(if (b * b - 4 * a * c) > 0 then
2
else
(if ((b * b - 4 * a * c) == 0) then 1 else 0))
In the expression:
if valid a b c == False then
"not a valid eq"
else
(if (b * b - 4 * a * c) > 0 then
2
else
(if ((b * b - 4 * a * c) == 0) then 1 else 0))
Failed, modules loaded: none.
Can someone explain to me what is wrong with this code? And how can i fix it? Thanks

Answer 1

As I already commented, you should always have a type signature, before even writing any actual code. First make it clear what the purpose of your code is, before actually implementing anything!
So, valid takes three numbers and checks them in some way, yielding False or True – i.e., a boolean. Hence, a valid signature would be
valid :: Int -> Int -> Int -> Bool
This would limit the arguments to machine-sized integers – fast but not overflow-safe. It could also be
valid :: Integer -> Integer -> Integer -> Bool
or, for floating-point real numbers,
valid :: Double -> Double -> Double -> Bool
In fact, you don't need to settle on a particular type: it can be any number type, it just needs to support equality comparison. The “correct” signature would be
valid :: (Num a, Eq a) => a -> a -> a -> Bool
That's indeed also what GHC infers if you just give it the code without a type signature:
Prelude> :t valid
valid :: (Eq a, Num a) => a -> a -> a -> Bool
But the compiler can only get this right by itself because the function valid happens to be type-correct. If you put in some mistake, then the compiler has no idea what the type should be, and hence likely infer some nonsensical type that leads to a cryptic error message. (This is only one of the reasons why you should write the signature first.)
That's what happened in nraized. This also takes three numbers and gives one number. Let's keep it simple:
valid :: Double -> Double -> Double -> Int
That should certainly be ok (though you can certainly make it more generic).
Now the error message is much clearer:
<interactive>:16:87:
Couldn't match expected type ‘Int’ with actual type ‘[Char]’
In the expression: "not a valid eq"
In the expression:
if valid a b c == False then
"not a valid eq"
else
(if (b ^ 2 - 4 * a * c) > 0 then
2
else
(if ((b ^ 2 - 4 * a * c) == 0) then 1 else 0))
What this tells you is that "not a valid eq" is incompatible with the type Int. Pretty obvious actually, isn't it? A function that's supposed to return 0, 1 or 2 shouldn't be able to return a string!
If you really want this to be an error case, you should mark it as such:
nRaizes a b c = if valid a b c == False then error "not a valid eq"
...
Here, the string is not a result: if that case is encountered, the program will simply be aborted and the error message prompted at the user, instead of trying to pass it on to further functions (which couldn't possibly give meaningful results anymore, just yet stranger errors).
A couple of stylistic notes
Generally avoid nesting if with explicit mention of True and False – this is needlessly complicated: comparisons yield booleans anyway. valid just gives false if any of the equalities hold; this could be written
valid a b c = if [a,b,c] == [0,0,0]
|| [a,b] == [0,0]
|| a == 0
then False
else True
...but that's just the same as
valid a b c = not ([a,b,c] == [0,0,0] || [a,b] == [0,0] || a == 0)
or indeed
valid a b c = [a,b,c] /= [0,0,0] && [a,b] /= [0,0] && a /= 0
Anyway, these checks are heavily redundant. If a is not 0 then the list equalities can't possibly hold either! So,
valid a b c = a /= 0
would work just as well. Actually you're not even using the b and c argument, so just write
valid a _ _ = a /= 0
...or just don't define valid by itself at all: simply inline the condition a /= 0.
nRaizes a b c = if (a /= 0) == False then error "not a valid eq"
...
which is of course again completely roundabout: simply use
nRaizes a b c = if a == 0 then error "not a valid eq"
...
That still leaves you with some ugly nested ifs in nasty nested parens. Haskellers don't like that, the preferred style is to use guards:
nRaizes a b c
| a == 0 = error "not a valid eq"
| b^2 - 4*a*c > 0 = 2
| b^2 - 4*a*c == 0 = 1
| otherwise = 0
Still not optimal: you're computing the discriminant twice. Why not:
nRaizes a b c
| a == 0 = error "not a valid eq"
| d > 0 = 2
| d == 0 = 1
| otherwise = 0
where d = b^2 - 4*a*c
While error can be used like that, I wonder why you check this anyway at that point. If a==0 then it's not really a second-order polynomial, but so what? It still has a number of solutions. Really the error case should probably if all the coefficients are zero (because the number of solutions would be infinite). Hence I think the code you really want is probably the following:
nRaizes :: (Eq a, Floating a) => a -> a -> a -> Int
nRaizes a b c
| all (==0) [a,b,c] = error "Equation has infinite solutions"
| d > 0 = 2
| d == 0 = 1
| otherwise = 0
where d = b^2 - 4*a*c