I've noticed more and more recently all of the Haskell code I see uses these language extensions at the beginning of every file. Some of them do pretty radical stuff; it seems pretty intimidating that to write an HTTP API-wrapper you need 5 extensions to the language. Is there a process by which these extensions get fully added into the language proper?
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/
I 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.
The 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.
I'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.
I 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).
It 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.
TH 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.
Yes, but it's a slow process and hasn't been active lately. There was a small update to the standard released in 2010 and the plan later on was to update the standard either yearly or on a rolling basis, but activity ended up dying down. The Haskell' committee[1] is in charge of updating the standard and has been rekindled recently, so we might see more updates to the core language standard in coming years.
Most of the commonly used extensions are in this vein, similar to Python's "import from future".
While some extensions will get folded into the language, others never will. For a few extensions, it's useful to have an explicit flag telling the compiler that yes, you actually want to do it: some things (like UndecideableInstances and OverloadedInstances) are sometimes useful and sometimes mistakes, so getting people to opt-in explicitly is useful. A few other extensions are too complex and GHC-specific (TemplateHaskell) or usually not used but kept around for backwards compatibility (Rank2Types, ImplicitParameters).
At the same time, I think it's also not as big an issue as people seem to think. For better or for worse, Haskell in practice is currently defined by GHC rather than a formal standard—not too different from other non-standardized languages. From this point of view, language extensions are part of the language proper, just hidden behind a flag. This is useful since de facto Haskell is a living, fast-changing language, so some way of managing the changes in your own code makes it much easier to keep up. I think of extensions as more like libraries that just happen to need access to the compiler than language extensions per se.
Think of turning on language extensions as importing a library. Lots and lots of language extensions are pretty much as benign as importing a standard library. Moving them into the language proper is an aesthetic issue that has minimal effect on writing production code.
[The analogy is, of course, not precise. Please don't respond as though I am implying it is.]
Oh don't be intimidated. They are a way for a language to evolve without breaking old code, it quite an interesting way to allow the 'language' to embrace changes. Just think of them as compiler level imports :)
The Haskell standard is, for great reason, rather conservative. Lots of extensions to the 98 and 2010 versions are popular, valid, and battle tested. Not all code requires them so there's little chance they will be incorporated, but there's also little reason to fear! Few extensions are dangerous—unfortunately it's not clearly documented which is which.
As a heavy user of Haskell professionally and personally, I think you are a great person if you write a binding to a C library. Any C library. So long as you do a reasonably thorough job. Covering the entire surface area of the library is fantastic.
The barest of C bindings, too. A minimal wrapper for memory management is a much better binding than one that hides the raw API behind an abstraction that may or may not be suitable for every use.
