4 ms·

> We're going to need a few language extensions, so let's get this out of the way first: {-# LANGUAGE RankNTypes, GADTs, MultiParamTypeClasses, Kin

> We're going to need a few language extensions, so let's get this out of the way first: {-# LANGUAGE RankNTypes, GADTs, MultiParamTypeClasses, KindSignatures, TypeApplications, FunctionalDependencies, FlexibleContexts, FlexibleInstances, UndecidableInstances, IncoherentInstances #-} Dang, how do you know to use that?

lalaithion 7y ago
There's a bunch here that are sort of "We need X so we also must enable Y and Z". For instance, FunctionalDependencies requires MultiParamTypeClasses and IncoherentInstances requires UndecideableInstances and FlexibleInstances.
kryptiskt 7y ago
Quite often the error messages will tell you what extension to enable to use that construct.
hopia 7y ago
This feels absurd indeed. Like half of the GHC extensions introduce only some trivial syntactical convenience whereas the other half each introduce practically a whole new language. This list aligns more with the latter description.
- tome 7y ago
  All of those extensions match the description of "things one thought that Haskell should have been able to do anyway" (some more tenuously than others, granted).
  - dllthomas 7y ago
    IncoherentInstances?
- gowld 7y ago
  I wish C++ features had that level of transparency and control.
choeger 7y ago
This is Haskell's equivalent of node.js' dependency hell.
- mcbuilder 7y ago
  Hardly, Cabal Hell is the Haskell equivalent. You can enable all these extensions module wide by putting them in your project file. This is more a case of having to learn a plethora of advanced Haskell extensions, and when to use them.
  - whateveracct 7y ago
    And cabal is vastly improved nowadays anyways. I'm not familiar with npm, but does it have anything like cabal's Nix-style builds?
- gowld 7y ago
  No, it's equivalent to python's "from __future__ import foo"
whateveracct 7y ago
The same way you know to import a library? It's just importable language features, mostly in existence to not force trade-offs or backwards incompatibility on everyone willy nilly. I thought it was weird when I moved from Scala to Haskell but now I am unimpeded by it thanks to practice.

lalaithion 7y ago

There's a bunch here that are sort of "We need X so we also must enable Y and Z". For instance, FunctionalDependencies requires MultiParamTypeClasses and IncoherentInstances requires UndecideableInstances and FlexibleInstances.

kryptiskt 7y ago

Quite often the error messages will tell you what extension to enable to use that construct.

hopia 7y ago

This feels absurd indeed. Like half of the GHC extensions introduce only some trivial syntactical convenience whereas the other half each introduce practically a whole new language. This list aligns more with the latter description.

tome 7y ago
All of those extensions match the description of "things one thought that Haskell should have been able to do anyway" (some more tenuously than others, granted).
- dllthomas 7y ago
  IncoherentInstances?
gowld 7y ago
I wish C++ features had that level of transparency and control.

choeger 7y ago

This is Haskell's equivalent of node.js' dependency hell.

mcbuilder 7y ago
Hardly, Cabal Hell is the Haskell equivalent. You can enable all these extensions module wide by putting them in your project file. This is more a case of having to learn a plethora of advanced Haskell extensions, and when to use them.
- whateveracct 7y ago
  And cabal is vastly improved nowadays anyways. I'm not familiar with npm, but does it have anything like cabal's Nix-style builds?
gowld 7y ago
No, it's equivalent to python's "from __future__ import foo"

whateveracct 7y ago

The same way you know to import a library? It's just importable language features, mostly in existence to not force trade-offs or backwards incompatibility on everyone willy nilly. I thought it was weird when I moved from Scala to Haskell but now I am unimpeded by it thanks to practice.