有没有人编译过所需的导入列表,以避免Haskell标准库中的"非多态"定义？

Question

我已经使用Haskell很长一段时间了.我越用它,就越爱上这门语言.我简直无法相信我已经用了近15年的时间使用其他语言.

然而,我慢慢地,但正在稳步增长厌倦了Haskell的标准库.我的主要忌讳的是"没有足够多态"的定义(Prelude.map,Control.Monad.forM_,等).我有很多Haskell源代码文件,其第一行看起来像

{-# LANGUAGE NoMonomorphismRestriction #-}

module Whatever where

import Control.Monad.Error hiding (forM_, mapM_)
import Control.Monad.State hiding (forM_, mapM_)
import Data.Foldable (forM_, mapM_)

{- ... -}

为了避免不断地保持我应该隐藏的定义,我希望有一个或少量的源代码文件将这个import样板包装成可管理的单元.

所以...

1. 还有其他人试过这样做吗？
2. 如果上一个问题的答案为"是",他们是否发布了生成的样板包装源代码文件？

Answer 1

它并不像你想象的那样清晰.我将列出我能想到的所有缺点:

首先,对这些功能的一般性有一定的限制.例如,现在我正在为包含普通类型的索引类型编写库.您提到的每个函数都有一个更通用的索引等价物.我希望每个人都能切换到我的图书馆吗？没有.

这是另一个例子.mapM函数定义了一个更高阶的仿函数,它满足Kleisli类中的仿函数法则:

mapM return = return
mapM (f >=> g) = mapM f >=> mapM g

所以我可以说你的可遍历泛化是错误的,而我们应该把它概括为只是一个更高阶的仿函数类的实例.

另外,请查看category-extras包,以获取包含所有示例的高阶类和函数的一些示例.

还有性能问题.许多更专业的功能都经过精心调优的实现,可显着提升性能.有时,类会公开允许更多高性能版本的方法,但有时它们不会.

还存在类型类重载的问题.我实际上更喜欢尽量减少对类型的使用,除非它们具有从理论而非方便中得出的合理定律.此外,类型类通常在单态性限制下表现不佳,我喜欢在没有签名的情况下为我的应用程序代码编写函数.

还有味道问题.很多人根本不同意什么是最好的Haskell风格.我们仍然无法就前奏曲达成一致.说到这一点,已经有很多尝试编写新的Prelude,但是没有人能够就什么是最好的达成一致,所以无论如何我们都默认回到Haskell98.

但是,我认为改善事物的整体精神是好的,进步的最大敌人是满足,但不要以为会有一个明确的正确方法来做所有事情.