Re:Vmap in Haskell
by lalaithion on Friday January 31, 2020 @11:52AM
(#22203146)
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.
Quite often the error messages will tell you what extension to enable to use that construct.
Re:Vmap in Haskell
by whateveracct on Friday January 31, 2020 @01:13PM
(#22203924)
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.
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.
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).
IncoherentInstances?
I wish C++ features had that level of transparency and control.
This is Haskell's equivalent of node.js' dependency hell.
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.
Re:Vmap in Haskell
by whateveracct on Friday January 31, 2020 @01:15PM
(#22203942)
And cabal is vastly improved nowadays anyways. I'm not familiar with npm, but does it have anything like cabal's Nix-style builds?
Dang, how do you know to use that?