RE: “Ambiguous type variable in the constraint” error in rewrite rule

Simon Peyton-Jones simonpj at microsoft.com
Mon Jul 16 10:06:01 CEST 2012


| > Ah!  This rule will only match if the LHS is
| >
| >         f (WriterT w Identity) ($fMonadWriterT w Identity dm
| > $fMonadIdentity)
| >
| > So it's a nested pattern match.  That makes the LHS match less often;
| namely only when the dictionary argument to 'f' is an application of
| $fMonadWriterT, the function that arises from the instance decl
| >     instance (Monoid w, Monad m) => Monad (WriterT w m) where
| 
| I was expecting that this rule will fire if I use function f in a
| larger function of type, say, Monoid w => (Int -> w) -> Writer w ().
| But does your finding mean that it will fire less often than this?

It probably should fire in that situation, but it's delicate, because it relies on the argument looking exactly like

f (WriterT w Identity) ($fMonadWriterT w Identity dm $fMonadIdentity)

and it's hard to know whether it will look exactly like that.  

It's also not immediately clear that this specialisation is a big win, is it?


|(I tried to see this by myself, but it is difficult for me to test it
| because in a small test program, inlining solves everything

You can stop "inlining solving everything" in a small test using {-# NOINLINE #-}.

Simon





More information about the Glasgow-haskell-users mailing list