On Wed, Jun 10, 2015 at 12:11 PM, Roman Cheplyaka wrote:

On 10/06/15 21:50, wren romano wrote:

...

On Thu, Jun 4, 2015 at 11:43 PM, Edward Z. Yang wrote:

...

GHC used to always generalize let-bindings, but our experience with GADTs lead us to decide that let should not be generalized with GADTs. So, it's not like we /wanted/ MonoLocalBinds, but that having them makes the GADT machinery simpler.

This blog post gives more details on the matter: https://ghc.haskell.org/trac/ghc/blog/LetGeneralisationInGhc7

The fact that -XGADTs (in isolation) implies -XMonoLocalBinds isn't the problem. The problem is, the order in which language pragma are offered should not matter. Whether I say {-# LANGUAGE GADTs, NoMonoLocalBinds #-} or {-# LANGUAGE NoMonoLocalBinds, GADTs #-} shouldn't matter. Both should mean the same thing, regardless of how annoying it may be to work in that language.

The current behavior may be surprising if you are not aware of it, but it's the only sensible one. Otherwise, what should the meaning of

{-# LANGUAGE MonoLocalBinds, NoMonoLocalBinds #-}

be?

Roman

Arguably it should be a compiler warning. -Nathan

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

On Jun 10, 2015 3:47 PM, "Roman Cheplyaka" wrote:

On 10/06/15 22:21, Nathan Bouscal wrote:

...

On Wed, Jun 10, 2015 at 12:11 PM, Roman Cheplyaka mailto:roma@ro-che.info> wrote:

On 10/06/15 21:50, wren romano wrote: > On Thu, Jun 4, 2015 at 11:43 PM, Edward Z. Yang

mailto:ezyang@mit.edu> wrote:

...

>> GHC used to always generalize let-bindings, but our experience >> with GADTs lead us to decide that let should not be generalized >> with GADTs. So, it's not like we /wanted/ MonoLocalBinds, but >> that having them makes the GADT machinery simpler. >> >> This blog post gives more details on the matter: >> https://ghc.haskell.org/trac/ghc/blog/LetGeneralisationInGhc7 > > The fact that -XGADTs (in isolation) implies -XMonoLocalBinds

isn't

...

> the problem. The problem is, the order in which language pragma

are

...

> offered should not matter. Whether I say {-# LANGUAGE GADTs, > NoMonoLocalBinds #-} or {-# LANGUAGE NoMonoLocalBinds, GADTs #-} > shouldn't matter. Both should mean the same thing, regardless of

how

...

> annoying it may be to work in that language.

The current behavior may be surprising if you are not aware of it,

but

...

it's the only sensible one. Otherwise, what should the meaning of

{-# LANGUAGE MonoLocalBinds, NoMonoLocalBinds #-}

be?

Roman

Arguably it should be a compiler warning.

You could have enabled one of them project-wise and the other one for a sepcific module. Being able to override extensions is useful.

It looks like https://ghc.haskell.org/trac/ghc/ticket/3085 would cover this situation

wren romano wrote:

On Wed, Jun 10, 2015 at 3:21 PM, Nathan Bouscal wrote:

...

...

The current behavior may be surprising if you are not aware of it, but it's the only sensible one. Otherwise, what should the meaning of

{-# LANGUAGE MonoLocalBinds, NoMonoLocalBinds #-}

be?

Arguably it should be a compiler warning.

+1.

I'd say, when a set of flags are mutually incompatible (e.g., {Foo, NoFoo}) then that should be a warning/error. Whereas with GADTs, we *recommend* (and by default assume) MonoLocalBinds, but GADTs are not *incompatible* with NoMonoLocalBinds. We already support defeasible recommendations (in practice, if not intentionally); why not remove the counterintuitive corner cases they create in the current implementation?

As for the complaint about project-wide vs file-specific language extensions: yes, it can be helpful to have overriding behavior; but having that behavior at the commandline or within a single file is counterintuitive at best. What I think would make more sense is a set-valued variant of the Last monad where each local collection of constraints (the collection given on the commandline, the collection given in the cabal file, the collection given in the Haskell file itself, etc) must be internally consistent, generating an error/warning if it is not. And then we simply have the more fine-grained constraint sets override the coarser-grained constraint sets.

This is exactly the conclusion I arrived at when re-designing the option handling in Darcs. There we have even more (four) sources for options; in decreasing order of precedence: hard-coded defaults, global (per user) defaults, local (per repo) defaults, command line. Each level is required to be consistent in itself, later levels override earlier ones. Experience with this scheme has been good so far. Cheers Ben -- "Make it so they have to reboot after every typo." ― Scott Adams