search

haskell / rfcs

This repo is archived, consider using https://github.com/ghc-proposals/ghc-proposals instead
98 stars 17 forks source link

Allow ExplicitForall by default #16

Open blamario opened 7 years ago

blamario commented 7 years ago

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

hvr commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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.