<p dir="ltr"><br>
On Jun 10, 2015 3:47 PM, "Roman Cheplyaka" <<a href="mailto:roma@ro-che.info">roma@ro-che.info</a>> wrote:<br>
><br>
> On 10/06/15 22:21, Nathan Bouscal wrote:<br>
> > On Wed, Jun 10, 2015 at 12:11 PM, Roman Cheplyaka <<a href="mailto:roma@ro-che.info">roma@ro-che.info</a><br>
> > <mailto:<a href="mailto:roma@ro-che.info">roma@ro-che.info</a>>> wrote:<br>
> ><br>
> >     On 10/06/15 21:50, wren romano wrote:<br>
> >     > On Thu, Jun 4, 2015 at 11:43 PM, Edward Z. Yang <<a href="mailto:ezyang@mit.edu">ezyang@mit.edu</a> <mailto:<a href="mailto:ezyang@mit.edu">ezyang@mit.edu</a>>> wrote:<br>
> >     >> GHC used to always generalize let-bindings, but our experience<br>
> >     >> with GADTs lead us to decide that let should not be generalized<br>
> >     >> with GADTs.  So, it's not like we /wanted/ MonoLocalBinds, but<br>
> >     >> that having them makes the GADT machinery simpler.<br>
> >     >><br>
> >     >> This blog post gives more details on the matter:<br>
> >     >>     <a href="https://ghc.haskell.org/trac/ghc/blog/LetGeneralisationInGhc7">https://ghc.haskell.org/trac/ghc/blog/LetGeneralisationInGhc7</a><br>
> >     ><br>
> >     > The fact that -XGADTs (in isolation) implies -XMonoLocalBinds isn't<br>
> >     > the problem. The problem is, the order in which language pragma are<br>
> >     > offered should not matter. Whether I say {-# LANGUAGE GADTs,<br>
> >     > NoMonoLocalBinds #-} or {-# LANGUAGE NoMonoLocalBinds, GADTs #-}<br>
> >     > shouldn't matter. Both should mean the same thing, regardless of how<br>
> >     > annoying it may be to work in that language.<br>
> ><br>
> >     The current behavior may be surprising if you are not aware of it, but<br>
> >     it's the only sensible one. Otherwise, what should the meaning of<br>
> ><br>
> >     {-# LANGUAGE MonoLocalBinds, NoMonoLocalBinds #-}<br>
> ><br>
> >     be?<br>
> ><br>
> >     Roman<br>
> ><br>
> ><br>
> > Arguably it should be a compiler warning.<br>
><br>
> You could have enabled one of them project-wise and the other one for a<br>
> sepcific module. Being able to override extensions is useful.</p>
<p dir="ltr">It looks like <a href="https://ghc.haskell.org/trac/ghc/ticket/3085">https://ghc.haskell.org/trac/ghc/ticket/3085</a> would cover this situation</p>