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@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

I do use the data Ex = forall a. ... syntax occasionally, but only when I'm emphasizing that I'm not building a GADT. I would entertain the thought of removing it. Yet, I don't think we can do so as part of this process, as we don't have a combination of extensions that allows GADT-syntax existentials but not this other syntax. (Even -XGADTs -XNoExistentialQuantification doesn't eliminate it.) In any case, I've voted against GADTs, and so if you want to disentangle this one piece of syntax, that would also be a vote against GADTs, followed up with a proposal to spin out this syntax into its own extension. Richard

On Dec 4, 2020, at 9:14 AM, Spiwack, Arnaud wrote:

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

It makes more than perfect sense, but I wasn't aware of this. A consequence of always enabling -XGADTs, I suppose :-) . _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

Hi, Am Freitag, den 04.12.2020, 15:47 +0100 schrieb Spiwack, Arnaud:

I'm just saying: let's _not_ add ExistentialQuantification in GHC2021 (because it ought, in my opinion, to be considered deprecated).

I’m convinced!

Let's not go into talking about chopping the feature into smaller pieces.

Not for GHC2021! But if GADTs don’t make it this round, we can ask the question if ExistentialVariables is a feature worth having on its own, of if anyone who wants to use that should just go for GADTs. Cheers, Joachim -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/