4 ms·
It is intimidating indeed. The unfortunate fact today is that you must understand and use several language extensions to write real production Haskell code. O
by chadaustin 11y ago
It is intimidating indeed. The unfortunate fact today is that you must understand and use several language extensions to write real production Haskell code. On the plus side, perhaps the right way to get started is to write everything out longhand and then when you find yourself asking "Man I wish the compiler could do all of this for me" then you'll know what extension to enable. :)
Many extensions (ExistentialQuantification, Rank2Types, RankNTypes, ScopedTypeVariables, TemplateHaskell) are necessary for writing certain types of code in Haskell. I would not be surprised at all to see them folded into the next official version of the Haskell language.
Others are very convenient but relatively benign syntax sugar (RecordWildCards, TupleSections, OverloadedStrings, LambdaCase, DeriveFoldable, DeriveFunctor, DeriveGeneric, DeriveTraversable). These extensions can obliterate huge amounts of boilerplate that you'd need to write otherwise.
Others are more experimental and will remain as extensions for a while.
I believe I heard that the Haskell Prime effort is going to start again, and a new version of the language will integrate the most important and mature extensions, but I'm not following very closely. https://prime.haskell.org/ https://prime.haskell.org/
- chriswarbo 11y agoI don't think TemplateHaskell will be folded into a standard any time soon. It's rather large (e.g. all the AST datatypes), and relatively unstable (e.g. GHC 7.8 to GHC 7.10 had breaking changes to TemplateHaskell).
- gh02t 11y agoIt also seems like a lot of people really dislike TH. Half the time I see "foo is great, but it uses Template Haskell," with the implication that that's a non-starter. Personally I don't have a strong opinion one way or another, but it looks to me like it's contentious enough that it won't be added.
- kyllo 11y agoTH is hard to debug. When you get an error message, you see the TH generated code, which can look very different from your source, and the line numbers are meaningless. It's also GHC specific so if you're one of those weirdos using a different Haskell compiler you can't use any library that requires TH.
- wyager 11y agoI heard ScopedTypeVariables is not in line to be added to the next standard. I thought it was a very innocuous extension, but apparently there are some reservations about it being difficult to add to certain alternate compiler types, and the committee wants to avoid favoring GHC's current implementation over other current and future implementations. I don't know if this is written down anywhere; it came up in conversation with a committee member.
- pash 11y agoThe big problem with ScopedTypeVariables is that it changes the meaning of existing code by unifying type variables that are not unified today in standardized Haskell. It's one of those things that you'd probably do if you were starting with a blank slate, but it's not worth breaking existing code for when you can instead get the functionality through an opt-in extension. GHC Haskell's language extensions are pretty nice that way, but it would be nice to standardize the extensions to open the (extended) language back up to alternative implementations.
- dllthomas 11y agoI'm inclined to agree with your conclusion, overall. In this case it's worth noting that the issue is ameliorated by the fact that ScopedTypeVariables can only change the meaning of code that already uses other extensions, since it only affects type variables explicitly listed in a forall, and by default you can't have explicit foralls.
- tel 11y agoHard to imagine not mentioning GADTs!
- chadaustin 11y agoGood point. :) Though honestly the only of my Haskell projects that used them was a type checker for a DSL that relied on GHC's own type checker. :)