[Haskell-cafe] GHCi's :t misbehaving

Luke Palmer 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
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 <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:
> <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 at flippac.org
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>


More information about the Haskell-Cafe mailing list