导入替代 Prelude 的方式有哪些优缺点？答案

【问题标题】：What are the pros and cons about the ways to import an alternative Prelude?导入替代 Prelude 的方式有哪些优缺点？
【发布时间】：2015-02-20 03:14:11
【问题描述】：

有很多替代方案（主观上）改进了标准的 Haskell Prelude。在开发应用程序时使用它们是有意义的，但如何最好地告诉您的编译器呢？

我的想法：

import qualified Prelude
import MyPrelude

但随后 HLint 抱怨导入 Prelude 合格是多余的。

{-# LANGUAGE NoImplicitPrelude #-}
import MyPrelude

这似乎可行，但相当冗长。

Some kind of global LANGUAGE pragma in the cabal file

还有其他方法吗？有没有公认的标准？

【问题讨论】：

我没有看到来自 HLint 的 hlint-1.9.16 的任何此类投诉。我认为前两个很好，我也看到了import Prelude () 的建议。我对 global pragma 持怀疑态度，因为这意味着源文件没有清楚地说明它导入的内容。
投票结束为“基于意见”：“最佳方式”含糊不清，对解释过于开放，无法鼓励有用的答案。通常认为请求“方法”是一种很好的形式；既然你已经有办法了，那你就需要说出你不喜欢那种方式的地方。
另外，请注意，GHC 的 Prelude 即将发生一些重大变化；但这是有争议的。 GHC 7.10 即将发布（它们在 RC2 上），计划从基于 List 的 Prelude 更改为更通用的 Prelude，实施者显然认为他们已经得到了 Haskell 社区的支持，但现在正在重新考虑这一变化。 https://ghc.haskell.org/trac/ghc/wiki/Prelude710
@DanielWagner 我应该问一下利弊，我会相应地改变我的问题。

标签： haskell

【解决方案1】：

如果你真的想导入一个独特的前奏，那么不导入标准前奏是正确的，因此

{-# LANGUAGE NoImplicitPrelude #-}
import MyPrelude

是标准方式。

【讨论】：