[Haskell-cafe] The evil GADTs extension in ghci 7.8.4 (maybe in other versions too?)

[wren romano]

On Wed, Jun 10, 2015 at 3:21 PM, Nathan Bouscal <nbouscal at gmail.com> 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.

(The only conceptual infelicity I can see to that approach is when we
enable certain flags because of other ones, like LiberalEverything
whenever we have FunDeps. In principle, if a constraint set further
down the line says NoFunDeps, then this should also disable the
LiberalEverything that depended on FunDeps —or at least, someone may
desire that behavior. Resolving this would require a rather
sophisticated model of intent behind enabling various language
extensions. A model I do not propose developing at present. However,
since we currently lack such facilities, we would lose nothing by not
having them in the simple approach proposed above.)

-- 
Live well,
~wren