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 st

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. [1]: https://prime.haskell.org/ https://prime.haskell.org/