4 ms·

Hiding the ways in which your code isn't really Haskell (e.g. isn't going to be compatible with other random Haskell code) doesn't strike me as a fix. Why are t

Hiding the ways in which your code isn't really Haskell (e.g. isn't going to be compatible with other random Haskell code) doesn't strike me as a fix. Why are there so many extensions in the first place?

MBCook 9y ago
Honestly this bugs me too. I don’t really see why the community doesn’t just decide the GHC really IS Haskell. I’m aware there are other compilers but basically everyone uses GHC. So all these things that have to be turned on because they’re not “compatible“ with all the other compilers that no one else uses just add complexity for new users (and I suppose current users.)
- yorwba 9y ago
  But are all those options compatible with each other?
  - forkerenok 9y ago
    No, they are not, and some are useless Edit: I guess not useless, but over time rendered as anti-features
    - tome 9y ago
      Can you name some extensions that are not compatible with each other. I can't, off the top of my head, and I've been using Haskell for some years. (I don't deny there might be some, but I'm finding it hard to think of any.)
      - shmish111 9y ago
        GeneralizedNewtypeDeriving and DeriveAnyClass (although this is fixed in 8.2)
  - jeremyjh 9y ago
    Yes they are but they may not be compatible with all existing code as it is presently written. For example turning on OverloadedStrings can introduce type ambiguity in existing code where the type of a string literal cannot be deduced.
- jcelerier 9y ago
  yeah and we should also have decreted that IE6 was Internet in 2003 because that's what everyone was using too
- marcosdumay 9y ago
  GHC or not, you simple do not want all the extensions active all the time.
dualogy 9y ago
"Extensions" has just turned out to be a sub-optimal moniker. They're not some third-party-compiler-plugins-to-be-installed-into-GHC, they're more like (rather involved) syntax sugars you can enable if needed. Each such "language feature" amounts to a tiny sub-compiler necessitating additional "core-to-core" and "core lint" (Core being the intermediate Typed Lambda Calculus representation all Haskell syntax sugars, built-in or "extension", compile down to) passes during compilation, which in GHC feels pretty sluggish to begin with. So in pragmatic terms, enabling/disabling "extensions" lets you prevent some unnecessary processing loads during compilation. Obviously one can do everything in "vanilla" (no-"extensions") Haskell just like one could express everything in raw Lambda Calculus. Syntax sugars as always allow for reducing patterns of verbosity --- those provided by "extensions" tend to be such patterns-of-verbosity that don't always occur in-all-projects-all-the-time, just in enough-projects-much-of-the-time. Most of the aversion to them seems kneejerk "but my other language had another (or none at all) approach to this" --- never understood the strong opinions about GHC extensions. "Other-language" typically also delights in a culture of repetetively verbose syntax itself and no such APIs to hack new language constructs into the compiler in a plug-and-play manner (without forking). And yes one can enable these via cabal file or GHC -X flags, but there's something to be said for per-module pragmas: they only activate where needed, and it aids the code reader as to what non-vanilla syntactic constructs are used in the-module-at-hand.
- tree_of_item 9y ago
  I'm aware that they're syntax sugar. I'm saying syntax sugar is bad. It's especially bad when there are dozens of mutually incompatible sugars. It's double especially bad when the base language is already one of the most complicated ones around.
  - tome 9y ago
    > there are dozens of mutually incompatible sugars If you think there are dozens then I challenge you to name a few ... (I can't, off the top of my head, think of any but I don't deny there may be some.)
  - njs12345 9y ago
tome 9y ago
> Hiding the ways in which your code isn't really Haskell (e.g. isn't going to be compatible with other random Haskell code) ... Haskell code with any extensions enabled is pretty much always compatible with Haskell code with any other extensions enabled. (I only said "pretty much" to hedge my bets. I literally can't think of any case where extensions could make your code incompatible with other code across a module boundary.)

MBCook 9y ago

Honestly this bugs me too. I don’t really see why the community doesn’t just decide the GHC really IS Haskell. I’m aware there are other compilers but basically everyone uses GHC. So all these things that have to be turned on because they’re not “compatible“ with all the other compilers that no one else uses just add complexity for new users (and I suppose current users.)

yorwba 9y ago
But are all those options compatible with each other?
- forkerenok 9y ago
  No, they are not, and some are useless Edit: I guess not useless, but over time rendered as anti-features
  - tome 9y ago
    Can you name some extensions that are not compatible with each other. I can't, off the top of my head, and I've been using Haskell for some years. (I don't deny there might be some, but I'm finding it hard to think of any.)
    - shmish111 9y ago
      GeneralizedNewtypeDeriving and DeriveAnyClass (although this is fixed in 8.2)
- jeremyjh 9y ago
  Yes they are but they may not be compatible with all existing code as it is presently written. For example turning on OverloadedStrings can introduce type ambiguity in existing code where the type of a string literal cannot be deduced.
jcelerier 9y ago
yeah and we should also have decreted that IE6 was Internet in 2003 because that's what everyone was using too
marcosdumay 9y ago
GHC or not, you simple do not want all the extensions active all the time.

dualogy 9y ago

"Extensions" has just turned out to be a sub-optimal moniker. They're not some third-party-compiler-plugins-to-be-installed-into-GHC, they're more like (rather involved) syntax sugars you can enable if needed. Each such "language feature" amounts to a tiny sub-compiler necessitating additional "core-to-core" and "core lint" (Core being the intermediate Typed Lambda Calculus representation all Haskell syntax sugars, built-in or "extension", compile down to) passes during compilation, which in GHC feels pretty sluggish to begin with. So in pragmatic terms, enabling/disabling "extensions" lets you prevent some unnecessary processing loads during compilation. Obviously one can do everything in "vanilla" (no-"extensions") Haskell just like one could express everything in raw Lambda Calculus. Syntax sugars as always allow for reducing patterns of verbosity --- those provided by "extensions" tend to be such patterns-of-verbosity that don't always occur in-all-projects-all-the-time, just in enough-projects-much-of-the-time. Most of the aversion to them seems kneejerk "but my other language had another (or none at all) approach to this" --- never understood the strong opinions about GHC extensions. "Other-language" typically also delights in a culture of repetetively verbose syntax itself and no such APIs to hack new language constructs into the compiler in a plug-and-play manner (without forking). And yes one can enable these via cabal file or GHC -X flags, but there's something to be said for per-module pragmas: they only activate where needed, and it aids the code reader as to what non-vanilla syntactic constructs are used in the-module-at-hand.

tree_of_item 9y ago
I'm aware that they're syntax sugar. I'm saying syntax sugar is bad. It's especially bad when there are dozens of mutually incompatible sugars. It's double especially bad when the base language is already one of the most complicated ones around.
- tome 9y ago
  > there are dozens of mutually incompatible sugars If you think there are dozens then I challenge you to name a few ... (I can't, off the top of my head, think of any but I don't deny there may be some.)
- njs12345 9y ago

tome 9y ago

> Hiding the ways in which your code isn't really Haskell (e.g. isn't going to be compatible with other random Haskell code) ... Haskell code with any extensions enabled is pretty much always compatible with Haskell code with any other extensions enabled. (I only said "pretty much" to hedge my bets. I literally can't think of any case where extensions could make your code incompatible with other code across a module boundary.)