[ghc-steering-committee] GHC2021: a final plea for ScopedTypeVariables

[Simon Peyton Jones]

Most of the criticisms are around the fact the the current manifestation is not ideal, something I agree with. I would say in this case we should not let perfect be the enemy of good: if during the years, once types in patterns or Dependent Haskell extensions require this, the scoping mechanism needs to change, we can do it. But as of now, ScopedTypeVariables is a very important piece in the flavour of Haskell in main usage (given its mainstream acceptance).

I agree with this.  Not having scoped type variables (in any form) is a huge blemish.  The existing design may not be perfect, but it’s worked rather well for a long time.

Simon

From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org> On Behalf Of Alejandro Serrano Mena
Sent: 07 December 2020 20:26
To: ghc-steering-committee at haskell.org
Subject: [ghc-steering-committee] GHC2021: a final plea for ScopedTypeVariables

Dear all,
I’ll try once again (this is the last one, I’ll promise) to convince the Committee of including ScopedTypeVariables as part of GHC2021. It has been with us for a long time — so their problems seem well understood — and the community seems to want it as part of this new “language version” — which means that people are really using it.

Most of the criticisms are around the fact the the current manifestation is not ideal, something I agree with. I would say in this case we should not let perfect be the enemy of good: if during the years, once types in patterns or Dependent Haskell extensions require this, the scoping mechanism needs to change, we can do it. But as of now, ScopedTypeVariables is a very important piece in the flavour of Haskell in main usage (given its mainstream acceptance).

forall (member :: Committee). Regards -> member
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201209/72622fb3/attachment.html>