有没有人在野外遇到过Monad Transformer？ [英] Has anyone ever encountered a Monad Transformer in the wild?

问题描述

在我的金融机构业务 - 后台IT领域，一个软件组件围绕着全局配置，记录进度，进行某种错误处理/计算短路是很常见的。哈斯克尔的Reader-，Writer-或Maybe-monads等都可以很好地建模，并与Monad变压器组合在一起。但是似乎有一些缺点：monad变压器背后的概念相当棘手难懂，monad变压器会导致非常复杂的类型签名，并且会导致一些性能损失

所以我想知道：在处理上述常见任务时，单体变压器是最佳做法吗？

解决方案

Haskell社区在这个问题上分歧。

• 约翰·休斯（John Hughes）报告说，他发现教导单体变压器比教导单子更容易，而且他的学生使用变压器第一方法做得更好。 >




• GHC开发人员通常避免使用单变形变压器，宁愿卷起自己的monads，整合所有需要的功能。 （我刚刚被告知，GHC将不会使用我三天前定义​​的单体变压器。）

$ b对于我来说，monad变压器很像无点编程（即没有命名变量的编程），这是有道理的;毕竟，它们在类型级别上正是无节点编程。我从来没有喜欢无点编程，因为可以引用偶尔的名字。

我在实践中观察到的是

• 可用于Hackage的单变形变压器数量非常好，其中大部分都很简单。这是一个经典的问题，比起滚动自己的实例，学习一个大型图书馆更难学习。




• 像作家，州和环境这样的Monads是这么简单，我对monad变压器看不到什么好处。




• 在单模变压器发光的模块化和重用。 Liang，Hudak和Jones在其具有里程碑意义的论文Monad变形金刚和模块化解释器。

处理上述常见任务？

我会说不是。那里的monad变压器是最佳实践是您拥有相关抽象的产品线，您可以通过以不同的方式撰写和重用单体变形金刚来创建。在这样的情况下，您可能会开发出一些对您的问题领域很重要的单变量变压器（如GHC被拒绝的），您（a）以多种方式组合它们; （b）为大多数变压器实现大量的再利用; （c）在每个monad变压器中封装了一些非常重要的东西。

我的GHC拒绝的单体变压器不符合任何标准（a）/（b）/ （c）以上。

In my area of business - back office IT for a financial institution - it is very common for a software component to carry a global configuration around, to log its progress, to have some kind of error handling / computation short circuit... Things that can be modelled nicely by Reader-, Writer-, Maybe-monads and the like in Haskell and composed together with monad transformers.

But there seem to some drawbacks: The concept behind monad transformers is quite tricky and hard to understand, monad transformers lead to very complex type signatures, and they inflict some performance penalty.

So I'm wondering: Are monad transformers best practice when dealing with those common tasks mentioned above?

解决方案

The Haskell community is split on this issue.

• John Hughes reports that he finds it easier to teach monad transformers than to teach monads, and that his students do better with a "transformers first" approach.

• The GHC developers generally avoid monad transformers, preferring to roll up their own monads which integrate all the features they need. (I was told just today in no uncertain terms that GHC will not use a monad transformer I defined three days ago.)

To me, monad transformers are a lot like point-free programming (i.e., programming without named variables), which makes sense; after all, they are exactly programming point-free at the type level. I've never like point-free programming because it's useful to be able to introduce the occasional name.

What I observe in practice is

• The number of monad transformers available on Hackage is very great, and most of them are pretty simple. This is a classic instance of the problem where it's harder to learn a large library than to roll your own instances.

• Monads like Writer, State, and Environment are so simple that I don't see much benefit to monad transformers.

• Where monad transformers shine is in modularity and reuse. This property is beautifully demonstrated by Liang, Hudak, and Jones in their landmark paper "Monad Transformers and Modular Interpreters".

Are monad transformers best practice when dealing with those common tasks mentioned above?

I would say not. Where monad transformers are best practice is where you have a product line of related abstractions which you can create by composing and reusing monad transformers in different ways. In a case like this you probably develop a number of monad transformers that are important for your problem domain (like the one that was rejected for GHC) and you (a) compose them in multiple ways; (b) achieve a significant amount of reuse for most transformers; (c) are encapsulating something nontrivial in each monad transformer.

My monad transformer which was rejected for GHC did not meet any of the criteria (a)/(b)/(c) above.

这篇关于有没有人在野外遇到过Monad Transformer？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！