[ghc-steering-committee] #380 GHC2021: Let's deprecate ExistentialQuantification

[Eric Seidel]

Ah one clarification, GADTSyntax alone does not enable existential types. You need to enable either ExistentialQuantification or full GADTs.

ghc2020.hs:8:3: error:
    • Data constructor ‘MkDyn’ has existential type variables, a context, or a specialised result type
        MkDyn :: forall a. Typeable a => a -> Dyn
        (Enable ExistentialQuantification or GADTs to allow this)
    • In the definition of data constructor ‘MkDyn’
      In the data type declaration for ‘Dyn’

But if we are going to enable GADTs by default, then there's still not much need for the old syntax.

On Fri, Dec 4, 2020, at 08:31, Eric Seidel wrote:
> I do use ExistentialQuantification on occasion, but mainly because I'm 
> used to it and don't often use GADT syntax. I'm not strongly attached 
> to it, in fact now that you spelled out the GADT version
> 
> > data Dyn where
> >   MkDyn :: forall a. Typeable a => a -> Dyn
> 
> I think that makes the existential quite a bit clearer, so I might 
> start using it :)
> 
> On Fri, Dec 4, 2020, at 08:22, Spiwack, Arnaud wrote:
> > Dear all,
> > 
> > ExistentialQuantification is one of the extensions that we are 
> > considering adding to GHC2021.
> > 
> > ExistentialQuantificaton enables the following syntax:
> > 
> > `data Dyn = forall a. Typeable a => MkDyn a
> > ` 
> > Has any of us actually used this syntax in recent years? I, personally, 
> > only use the equivalent GADT syntax
> > 
> > `data Dyn where
> >   MkDyn :: forall a. Typeable a => a -> Dyn a
> > ` 
> > It’s barely more verbose, and it’s less quirky.
> > 
> > Besides, the GADT syntax is there to stay (and GADTSyntax at the very 
> > least, is one of these extensions where there seems to be no doubt will 
> > be in GHC2021).
> > 
> > I’d say there is such a thing as too much syntax. And, in my view, the 
> > GADT syntax makes the ExistentialQuantification syntax redundant. I’d 
> > much rather we didn’t add it in the defaults so that it can be on its 
> > slow path to deprecation.
> > 
> > /Arnaud
> > 
> > _______________________________________________
> > ghc-steering-committee mailing list
> > ghc-steering-committee at haskell.org
> > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> >