Yes, but it&#x27;s a slow process and hasn&#x27;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&#x27; 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.<p>Most of the commonly used extensions are in this vein, similar to Python&#x27;s &quot;import from future&quot;.<p>While some extensions will get folded into the language, others never will. For a few extensions, it&#x27;s useful to have an explicit flag telling the compiler that <i>yes</i>, 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).<p>At the same time, I think it&#x27;s also not as big an issue as people seem to think. For better or for worse, Haskell <i>in practice</i> 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 <i>de facto</i> 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 <i>per se</i>.<p>[1]: <a href="https:&#x2F;&#x2F;prime.haskell.org&#x2F;" rel="nofollow">https:&#x2F;&#x2F;prime.haskell.org&#x2F;</a>