
I have some mildly complicated parsing code, that uses parsec to return a computation (in a state monad) that handles operator precedence - so I can handle scoped precedence/fixities, much like in Haskell. I just spent a while bolting on some new features. More time than I'd like, I'd left it alone for a while and it took a bit of time getting my head around it again enough to be okay doing folds on parse results and the like. Enough so that I've been leaning on the type checker to tell me when I've messed up! So, I have something that loads into ghci okay now. I go to check the type of one of the functions using :t and get this error: <interactive>:1:0: Ambiguous type variable `m' in the constraint: `Monad m' arising from a use of `constructor' at <interactive>:1:0-10 Probable fix: add a type signature that fixes these type variable(s) Now I'm not about the supply the type signature, that's what I asked it for! And it ought to typecheck okay, given that the code loaded in the first place. I'm about to turn in for the night, but I'm wondering what's going on here. Anyone? -- flippa@flippac.org

It's very hard to tell what is going on without more details. If you
*at least* give the ghci session, and possibly the whole code (while
it might be too much to read, it is not to much to load and try
ourselves).
This looks like a monomorphism restriction, which shouldn't happen
when you are using :t. So that's why more info is necessary.
Luke
On Tue, Nov 17, 2009 at 6:31 PM, Philippa Cowderoy
I have some mildly complicated parsing code, that uses parsec to return a computation (in a state monad) that handles operator precedence - so I can handle scoped precedence/fixities, much like in Haskell. I just spent a while bolting on some new features. More time than I'd like, I'd left it alone for a while and it took a bit of time getting my head around it again enough to be okay doing folds on parse results and the like. Enough so that I've been leaning on the type checker to tell me when I've messed up!
So, I have something that loads into ghci okay now. I go to check the type of one of the functions using :t and get this error: <interactive>:1:0: Ambiguous type variable `m' in the constraint: `Monad m' arising from a use of `constructor' at <interactive>:1:0-10 Probable fix: add a type signature that fixes these type variable(s)
Now I'm not about the supply the type signature, that's what I asked it for! And it ought to typecheck okay, given that the code loaded in the first place. I'm about to turn in for the night, but I'm wondering what's going on here. Anyone?
-- flippa@flippac.org _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

Luke Palmer wrote:
It's very hard to tell what is going on without more details. If you *at least* give the ghci session, and possibly the whole code (while it might be too much to read, it is not to much to load and try ourselves).
This looks like a monomorphism restriction, which shouldn't happen when you are using :t. So that's why more info is necessary.
I was using GHC 6.10.3 because I'd not felt like building my own gtk2hs on windows - it looks like it's fixed in 6.10.4, there was a remaining type error that 6.10.3 wasn't flagging up. -- flippa@flippac.org

Are you wanting the type of a variable? You probably want :i
What is the actual type of the variable? Or is it an expression?
Without more info it's hard to help. You should be able to make a repo case without all the supporting code by defining
thing1 ::
participants (3)
-
Luke Palmer
-
Philippa Cowderoy
-
Simon Peyton-Jones