5 ms·

You can set all the flags in your cabal file. How is this not a fix? This is like specifying your compiler version. We have a fairly hefty haskell code base at

You can set all the flags in your cabal file. How is this not a fix? This is like specifying your compiler version. We have a fairly hefty haskell code base at work, and we never use LANGUAGE pragmas anywhere.

tree_of_item 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) 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
As a Java programmer, I don’t have to have the equivalent of 75 LANGUAGE pragmas to be able to use the features in Java 8 instead of what Java 1.1 shipped with. It’s nice there’s a way not to put them at the top of every single file but they still exist. There must be some reasonable subset that basically everyone uses and should just be included in the language.
- donovanm 9y ago
  Getting everyone to come to a consensus on what should or shouldn't be included would be very difficult. Then there's also the issue of backwards compatibility. At the end of the day they're opt in so you can just simply not use them.
  - bunderbunder 9y ago
    Optimizing individually for every individual has a tendency to de-optimize the community as a whole. This is one of those things that seriously limits Haskell's growth. It's something for new users to bounce off of, and that contributes to Haskell's reputation as a write-only language.
- Jaxan 9y ago
  I think the equivalent is packages which provide annotations. There are plentiful of such packed providing variations of "notNull". It seems even worse than extensions, as they are third party.
- merb 9y ago
  actually in java you can have compiler extensions aswell. they are just not included by default.
- marcosdumay 9y ago
  > There must be some reasonable subset that basically everyone uses and should just be included in the language. Well, there is. The problem is that the last reasonable subset is 7 years old, and Haskell is evolving quickly. There's a new standard scheduled to 2020.
Tarean 9y ago
There are some extensions like UndecidableInstances or OverloadableSyntax which are great in specific files but which would be awful in the entire codebase.

tree_of_item 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) 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

As a Java programmer, I don’t have to have the equivalent of 75 LANGUAGE pragmas to be able to use the features in Java 8 instead of what Java 1.1 shipped with. It’s nice there’s a way not to put them at the top of every single file but they still exist. There must be some reasonable subset that basically everyone uses and should just be included in the language.

donovanm 9y ago
Getting everyone to come to a consensus on what should or shouldn't be included would be very difficult. Then there's also the issue of backwards compatibility. At the end of the day they're opt in so you can just simply not use them.
- bunderbunder 9y ago
  Optimizing individually for every individual has a tendency to de-optimize the community as a whole. This is one of those things that seriously limits Haskell's growth. It's something for new users to bounce off of, and that contributes to Haskell's reputation as a write-only language.
Jaxan 9y ago
I think the equivalent is packages which provide annotations. There are plentiful of such packed providing variations of "notNull". It seems even worse than extensions, as they are third party.
merb 9y ago
actually in java you can have compiler extensions aswell. they are just not included by default.
marcosdumay 9y ago
> There must be some reasonable subset that basically everyone uses and should just be included in the language. Well, there is. The problem is that the last reasonable subset is 7 years old, and Haskell is evolving quickly. There's a new standard scheduled to 2020.

Tarean 9y ago

There are some extensions like UndecidableInstances or OverloadableSyntax which are great in specific files but which would be awful in the entire codebase.