mtl，变形金刚，monads-fd，monadLib和选择的悖论 [英] mtl, transformers, monads-fd, monadLib, and the paradox of choice

问题描述

Hackage提供了一些monad变换器的软件包：

• mtl ：Monad转换器库


• 变形金刚：具体仿函数和monad变形金刚


• monads-fd ：Monad类，使用函数依赖


• monads-tf ：Monad类，使用类型族


• monadLib ：一组monad变换器。


• mtl-tf ：使用类型系列的Monad变换器库。


• mmtl ：Modular Monad tra nsformer library


• mtlx ：带有类型索引的Monad转换器库，提供'免费'副本。


• 撰写 - a>：可组合的monad变形金刚

（也许我错过了一些）

我们应该使用哪一个？

mtl是Haskell Platform中的一个，但我一直听到reddit的说法，它并不冷酷。

但是选择有什么不好，是不是只是一件好事？

好吧，我看到了例如数据访问器的作者必须使所有这些才能迎合流行的选择：
$ b

• data-accessor-monadLib库：monadLib monads的访问器函数
>

• data-accessor-monads-fd库：使用Accessor访问monads-fd中的状态monad class


• data-accessor-monads-tf libr ary：使用访问器访问monads-tf状态monad类型的状态
  
• data-accessor-mtl library：使用访问器访问mtl状态monad类中的状态
  
• data-accessor-transformers library：使用Accessor访问变换器状态monad

我想象如果这样继续并且例如几个竞争性的箭头包发展，我们可能会看到类似：spoonklink-arrows-transformers，spoonklink-arrows-monadLib，spoonklink-tfArrows-transformers，spoonklink-tfArrows-monadLib，...

然后我担心如果spoonklink被分叉，Hackage将用完磁盘空间。 ：）

问题：

• 为什么会有这么多monad变压器包？


• 为什么mtl [认为]不酷？


• 
  
• 这些关键区别有哪些？看似相互竞争的软件包由Andy Gill编写，由Ross Paterson维护。这是否意味着这些软件包没有竞争，而是以某种方式一起工作？安迪和罗斯认为他们自己的软件包是否已过时？


• 您和我使用哪一种？

<

• <$ c解析方案

$ c> mtl 使用GHC扩展，但是变换器是Haskell 98.

monads-fd 和 monads-tf 是附加到变形金刚依赖项和类型族，它们都提供 mtl 中缺少变形金刚的功能。

mtl-tf 是使用类型系列重新实现的 mtl 。

因此，本质上， mtl == 变形金刚 ++ monads-fd ， mtl-tf == 变形金刚 ++ 单子-TF 。我认为，变形金刚及其相关软件包的改进的可移植性和模块性是为什么 mtl 这些日子不冷酷的原因。 p>



mmtl 和 mtlx 两者似乎都和/或基于 mtl ，API差异和额外功能。



MonadLib 似乎有不同的看法，但我并不直接熟悉它。也似乎使用了很多的GHC扩展，比其他的更多。





一目了然 compose-trans 似乎更像是元程序创建monad变压器的东西。它声称与 Control.Monad.Trans 兼容......我猜的意思是 mtl ？





无论如何，我会建议以下决策算法：





• 您是否需要标准monads为新项目？使用变形金刚&帮助我们 mtl 休息。


• 您是否已经使用 mtl 变形金刚并不完全兼容，但没有人会因为不进行切换而杀了你。


• 其他软件包是否提供特殊功能你需要吗？不妨使用它，而不是自己滚动。


• 仍然不满意？把它们全部扔出去，下载 category-extras ，并用一页半的解决所有世界上的问题，难以理解的抽象废话令人叹为观止的通用代码。
  



Hackage has several packages for monad transformers:

• mtl: Monad transformer library
• transformers: Concrete functor and monad transformers
• monads-fd: Monad classes, using functional dependencies
• monads-tf: Monad classes, using type families
• monadLib: A collection of monad transformers.
• mtl-tf: Monad transformer library using type families.
• mmtl: Modular Monad transformer library
• mtlx: Monad transformer library with type indexes, providing 'free' copies.
• compose-trans: Composable monad transformers

(and maybe I missed some)

Which one shall we use?

mtl is the one in the Haskell Platform, but I keep hearing on reddit that it's uncool.

But what's bad about choice anyway, isn't it just a good thing?

Well, I saw how for example the authors of data-accessor had to make all these to cater to just the popular choices:

• data-accessor-monadLib library: Accessor functions for monadLib's monads
• data-accessor-monads-fd library: Use Accessor to access state in monads-fd State monad class
• data-accessor-monads-tf library: Use Accessor to access state in monads-tf State monad type family
• data-accessor-mtl library: Use Accessor to access state in mtl State monad class
• data-accessor-transformers library: Use Accessor to access state in transformers State monad

I imagine that if this goes on and for example several competing Arrow packages evolve, we might see something like: spoonklink-arrows-transformers, spoonklink-arrows-monadLib, spoonklink-tfArrows-transformers, spoonklink-tfArrows-monadLib, ...

And then I worry that if spoonklink gets forked, Hackage will run out of disk space. :)

Questions:

• Why are there so many monad transformer packages?
• Why is mtl [considered] uncool?
• What are the key differences?
• Most of these seemingly competing packages were written by Andy Gill and are maintained by Ross Paterson. Does this mean that these packages are not competing but rather work together in some way? And do Andy and Ross consider any of their own packages as obsolete?
• Which one should you and I use?

解决方案

A bunch of them are almost completely equivalent:

• mtl uses GHC extensions, but transformers is Haskell 98.
• monads-fd and monads-tf are add-ons to transformers, using functional dependencies and type families respectively, both providing the functionality in mtl that's missing from transformers.
• mtl-tf is mtl reimplemented using type families.

So essentially, mtl == transformers ++ monads-fd, mtl-tf == transformers ++ monads-tf. The improved portability and modularity of transformers and its associated packages is why mtl is uncool these days, I think.

mmtl and mtlx both seem to be similar to and/or based on mtl, with API differences and extra features.

MonadLib seems to have a rather different take on matters, but I'm not familiar with it directly. Also seems to use a lot of GHC extensions, more than the others.

At a glance compose-trans seems to be more like metaprogramming stuff for creating monad transformers. It claims to be compatible with Control.Monad.Trans which... I guess means mtl?

At any rate, I'd suggest the following decision algorithm:

• Do you need standard monads for a new project? Use transformers & co., help us lay mtl to rest.
• Are you already using mtl in a large project? transformers isn't completely compatible, but no one will kill you for not switching.
• Does one of the other packages provide unusual functionality that you need? Might as well use it rather than rolling your own.
• Still unsatisfied? Throw them all out, download category-extras, and solve all the world's problems with a page and a half of incomprehensible abstract nonsense breathtakingly generic code.

这篇关于mtl，变形金刚，monads-fd，monadLib和选择的悖论的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！