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
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
Hi, Am Mittwoch, den 09.12.2020, 12:08 +0000 schrieb Simon Peyton Jones via ghc-steering-committee:
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.
The same is true for ViewPatterns, which are even more harmless (clear syntactic opt-in; no spooky effect at a distance when type signature and definition are far apart). There we argued that the fact that we don’t think it’s perfect, and some wiki page with an alternative design exists, was enough to plea against it. Here, the situation seems equivalent (we know of better designs, namely binding type variables on the LHS of the equation). Can we justify why we go one way here and another way there? Is it because ViewPatterns are just mere convenience, and ScopedTypeVariables are absolutely needed for some things? Cheers, Joachim -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/
On 9 Dec 2020 at 14:40:13, Joachim Breitner
Hi,
Am Mittwoch, den 09.12.2020, 12:08 +0000 schrieb Simon Peyton Jones via ghc-steering-committee:
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.
The same is true for ViewPatterns, which are even more harmless (clear syntactic opt-in; no spooky effect at a distance when type signature and definition are far apart).
There we argued that the fact that we don’t think it’s perfect, and some wiki page with an alternative design exists, was enough to plea against it.
Here, the situation seems equivalent (we know of better designs, namely binding type variables on the LHS of the equation).
Can we justify why we go one way here and another way there? Is it because ViewPatterns are just mere convenience, and ScopedTypeVariables are absolutely needed for some things?
This is what I think at least (I also voted ‘yes’ for ViewPatterns, but I wouldn’t mind not having them). No ViewPatterns, I just need one extra ‘case’ to stay in GHC2021. Alejandro
On Wed, 9 Dec 2020 at 13:40, Joachim Breitner
Hi,
Am Mittwoch, den 09.12.2020, 12:08 +0000 schrieb Simon Peyton Jones via ghc-steering-committee:
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.
The same is true for ViewPatterns, which are even more harmless (clear syntactic opt-in; no spooky effect at a distance when type signature and definition are far apart).
There we argued that the fact that we don’t think it’s perfect, and some wiki page with an alternative design exists, was enough to plea against it.
Here, the situation seems equivalent (we know of better designs, namely binding type variables on the LHS of the equation).
Can we justify why we go one way here and another way there? Is it because ViewPatterns are just mere convenience, and ScopedTypeVariables are absolutely needed for some things?
Yes to your last point here. But other points to note about ViewPatterns: Technically ViewPatterns are not just a convenience, at least when combined with PatternSynonyms. The only way that you can write a PatternSynonym that does some arbitrary computation in the pattern is to use ViewPatterns - *this* is the killer feature of PatternSynonyms, because it provides full power to abstract over constructor names. You can define a constructor that expands to some arbitrary computation in the pattern. Here's an example: https://stackoverflow.com/questions/43838550/using-viewpatterns-and-patterns... (The alternative ViewPatterns design would also provide this functionality, incidentally.) But anyway, this is not an argument to accept ViewPatterns, because it doesn't look like PatternSynonyms will be in GHC2021 (shame!). Outside of the PatternSynonyms use-case, I don't think ViewPatterns are all that widely used. We have figures of 7% proliferation and 20% popularity, but that doesn't tell us (1) how much the extension is really used, and (2) how often it is used because it's the only way to do certain things with PatternSynonyms. Some more data would be nice. I base my intuition here on the fact that I hardly ever encounter any ViewPatterns, but I could well be living in a bubble of some kind. If the extension really isn't very widely-used, and we think the design might change, we can limit the churn in the future by avoiding having the extension on by default. Cheers Simon
Cheers, Joachim
-- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/
_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
participants (4)
-
Alejandro Serrano Mena -
Joachim Breitner -
Simon Marlow -
Simon Peyton Jones