[Haskell-cafe] Enabling GADTs breaks Rank2Types code compilation - Why?

[austin seipp]

On Tue, May 31, 2011 at 11:13 PM,
<dm-list-haskell-cafe at scs.stanford.edu> wrote:
> It definitely felt like I was running up against something like the
> monomorphism restriction, but my bindings were function and not
> pattern bindings, so I couldn't understand what was going on.  I had
> even gone and re-read the GHC documentation
> (http://www.haskell.org/ghc/docs/7.0-latest/html/users_guide/data-type-extensions.html#gadt),
> which says that -XGADTs enables -XRelaxedPolyRec, but makes no mention
> of -XMonoLocalBinds.
>
> It might save users some frustration if the GHC manual and/or the
> error message mentioned something about let bindings being monomorphic
> by default.

I'd agree it should be documented behavior and put somewhere in the
users guide. It's bitten a few people before, but Simon's blog post is
the only reference I've really seen on the matter I think.

> However, is it reasonable to conclude that if
> I'm going to use GADTs anyway, then additionally enabling
> ScopedTypeVariables doesn't really make my code any less future-proof?

I'd say so. For nontrivial extensions like this, I'd wager you're
likely to rely on GHC inadvertently in some form anyway - a result of
all this new typechecking stuff for example, is that GHC can correctly
infer types for more programs involving these complex extensions. You
may end up relying on such inference in the future, as we've already
seen happen here, which could break things down the road.
ScopedTypeVariables seems much more simple and future proof in this
regard, IMO.

-- 
Regards,
Austin