[Haskell-cafe] GHCi's :t misbehaving
lrpalmer at gmail.com
Tue Nov 17 21:30:59 EST 2009
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
This looks like a monomorphism restriction, which shouldn't happen
when you are using :t. So that's why more info is necessary.
On Tue, Nov 17, 2009 at 6:31 PM, Philippa Cowderoy <flippa at flippac.org> wrote:
> 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:
> 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 at flippac.org
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
More information about the Haskell-Cafe