The following code has ambiguity, but I can't figure out how to get around it. Am I missing something trivial? Am I going in the wrong direction? Thank you in advance for your time and for any help that you can offer.
data MehQueue = MehQueue
class MehBase a where new :: IO a instance MehBase MehQueue where new = return MehQueue
class (MehBase a) => HasShift a where shift :: a -> IO a instance HasShift MehQueue where shift a = return a
main :: IO () main = do x <- new shift x return ()
Please note that I intend to extend this example with MehStack, HasPush and HasPop. You can probably guess where I'm going with all this.
On 4/16/07, Paul Wankadia <junyer@gmail.com> wrote:
The following code has ambiguity, but I can't figure out how to get around it. Am I missing something trivial? Am I going in the wrong direction? Thank you in advance for your time and for any help that you can offer.
How about changing
x <- new
to
x <- new :: IO MehQueue
? I'm not a professional haskeller, probably there's a better alternative =). Cheers, -- Felipe.
On 16/04/07, Paul Wankadia <junyer@gmail.com> wrote:
Is it impossible for the compiler to infer the type from the methods called?
Your code:
main :: IO () main = do x <- new
From the use of 'new', the compiler can infer that the type of x is an instance of MehBase, and...
shift x
from the use of 'shift', that it is an instance of HasShift.
return ()
So we have x :: (MehBase a, HasShift a) => a. There isn't enough information provided to pin down 'a' any more precisely, so GHC can't figure out which 'new' or 'shift' you mean (remember that type classes provide overloading), and gives up. There is one special case where the compiler does infer a specific type despite not having enough information to do so, and that is where the class(es) is/are numeric. For example (Floating a) => a might default to Float or Double. This is one case where the compiler decides it can make 'reasonable' assumptions as to what you actually wanted. It's also why ambiguous types seem to work in the interpreter, if you've only ever looked at numeric ones. In the case of the code you posted, GHC isn't smart enough to realise that there's only one type in scope that satisfies the constraints. Here's the relevant part of the report: http://www.haskell.org/onlinereport/decls.html#sect4.3.4 Felipe's suggestion is probably the best way to fix it, i.e. tell the compiler exactly which type you want. The report seems to suggest you can give the compiler a list of defaults in the module declaration but I don't know if that would be sensible. -- Peter Berry <pwberry@gmail.com> Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html
participants (3)
-
Felipe Almeida Lessa -
Paul Wankadia -
Peter Berry