Should I use GHC Haskell extensions or not?

As I am learning Haskell, I see that there is a lot of language extensions used in real life code. As a beginner, should I learn to use them, or should I avoid them at all cost? I see that it breaks compatibility with Haskell 98 and limits code to pretty much GHC only. However, if I browse packages on Hackage, I see that most of them are GHC-only anyway.

So, what is an attitude of community towards using language extensions?

And if use of extensions is OK, how can I distinguish extensions which I can use “safely” (those which are likely to become part of the next Haskell standard) from those which are mostly “experimental”? For example, I suppose that -XDisambiguateRecordFields is nice and useful, but is it likely to be supported in the future?

6070 次浏览
小开

Generally speaking people do use GHC extensions quite heavily, because they're so useful and Haskell 98 is quite old. Once there's a more up to date standard people may make more effort to stick to it.

You can find the status of proposals for the next standard here.

小开

Yes, use extensions as appropriate.

But be sure to enable them intentionally -- only when you decide you need them. Do this on a per-module basis via {-# LANGUAGE Rank2Types #-} (for example).

小开
最佳答案

There are some GHC extensions that are too good to live without. Among my favorites are

  • Multiparameter type classes
  • Scoped type variables
  • Higher-rank types
  • Generalized algebraic data types (GADTs)

Of these the really essential one is multiparameter type classes.

Some GHC extensions are very speculative and experimental, and you may want to use with caution. A good way to identify a stable and trusted extension is to see if it is slated for inclusion in Haskell Prime, which is hoped to be the successor the Haskell 98.

I second Don Stewart's suggestion that every extension should be marked using the LANGUAGE pragma in the source file. Don't enable extensions using command-line options.

小开

The other answers here are good ones. I would add that GHC extensions are not as future-vulnerable (*) as they might be, because GHC seems to be far and away the most popular Haskell compiler, and I don't see that changing soon.

(*) as in the opposite of "future-proof"


提交答案