Allow ExplicitForall by default

[blamario]

Rendered version: https://github.com/blamario/rfcs/blob/explicit-forall/0000-explicit-forall.rst

[hvr]

Btw, here's the original proposal from the Prime wiki with which may save us some time rediscovering information: https://prime.haskell.org/wiki/ExplicitForall (& the linked discussion at https://mail.haskell.org/pipermail/haskell-prime/2009-June/002786.html which maybe should be summarised)

[evincarofautumn]

Like you, I would prefer to jump straight to ScopedTypeVariables, but this seems like a good first step.

Aside: I have actually named a function forall before (in a compiler where I wanted forall $ \ a b -> Fun a b to generate fresh type variables for a & b), but it’s not a big deal to change it to forAll or whatever.

[goldfirere]

The reason instance forall exists is that it gives a canonical place to put kind signatures on type variables. This is important when the kind of a type variable cannot be inferred (because it's a type family, say). On a class declaration, the type variables are actually brought into scope in the declaration head, so we have a canonical place without the forall.

Separately, I favor making forall a full-on keyword -- it leads to fewer special cases in the lexer, etc., and is easier for tools to support.

[blamario]

Btw, here's the original proposal from the Prime wiki with which may save us some time later: https://prime.haskell.org/wiki/ExplicitForall

Thank you. The present proposal can be seen as a condensed version of the second variant (i.e., no new reserved word) of the previous Prime proposal.

[blamario]

The reason instance forall exists is that it gives a canonical place to put kind signatures on type variables.

Ah. That did not occur to me. I'm not sure if it should be added to this proposal, as it would have no purpose without FlexibleInstances and KindSignatures at the minimum... perhaps even TypeFamilies, as you suggest.

Separately, I favor making forall a full-on keyword -- it leads to fewer special cases in the lexer, etc., and is easier for tools to support.

If we were discussing a new language design, I'd agree. In this situation, I think it's best to hew as closely to GHC as possible.