blocks|key|1260789|text|当我还在学习monads时，我使用StateT+ContT+IO堆栈构建了一个应用程序来创建离散事件模拟库；continuations用于存储单线程，StateT保存可运行线程队列和用于等待各种事件的挂起线程的其他队列。它工作得很好。我不知道如何为newtype包装器编写Monad实例，所以我只是把它变成了一个类型同义词，而且效果很好。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1260790|这些天，我可能会从头开始开发我自己的monad。然而，每当我这样做的时候，我发现自己正在查看"All+About+Monads“和MTL的源代码，以提醒我绑定操作是什么样子的，所以在某种意义上，我仍然在考虑MTL堆栈，即使结果是一个自定义的monad。|1260791|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

Back when I was learning monads I built an application using a stack of StateT ContT IO to create a discrete event simulation library; the continuations were used to store monadic threads, with the StateT holding the runnable thread queue and other queues used for suspended threads waiting for various events. It worked quite well. I couldn't figure out how to write the Monad instance for a newtype wrapper, so I just made it a type synonym and that worked pretty well.

These days I would probably have rolled my own monad from scratch. However whenever I do this I find myself looking at "All About Monads" and the source of the MTL to remind me what the bind operations look like, so in a sense I'm still thinking in terms of an MTL stack even though the result is a custom monad.

blocks|key|1045925|text|我最近“爱上”了F#上下文中的monad组合。我写了一个依赖于状态monad的DSL+:所有组件都依赖于状态monad:解析器(基于状态monad的解析器monad)，变量匹配表(内部类型不止一个)，标识符查找表。当这些组件一起工作时，它们依赖于相同的状态monad。因此，有一个将不同的本地状态组合在一起的状态组合的概念，以及一个为每个algo提供自己的状态可见性的状态访问器的概念。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1045926|最初，它的设计真的是“一个大的国家单子”。但是后来我开始需要只有本地生命周期的状态，但仍然在“持久”状态的上下文中(同样，所有这些状态都是由状态单体管理的)。为此，我确实需要引入状态monad转换器，以增强状态并一起调整状态monad。我还添加了一个转换器来在状态monad和延续状态monad之间自由移动，但我并没有费心去使用它。|1045927|因此，回答这个问题:是的，monad+transformers存在于“荒野”中。然而，我强烈反对“开箱即用”。使用简单的构建块编写您的应用程序，在模块之间使用手工制作的小桥，如果您最终使用像monad+transformer这样的东西，那很好；不要从那里开始。|1045928|关于类型签名:我开始认为这种类型的编程非常类似于玩蒙眼国际象棋(我不是一个棋手)：你的技能水平需要达到你“看到”你的函数和类型相匹配的程度。类型签名通常会让人分心，除非您出于安全原因显式添加类型约束(或者因为编译器强制您提供类型约束，例如使用F#记录)。|1045929|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|L|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|M|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

I recently "fell" on monad composition in the context of F#. I wrote a DSL with a strong reliance on the state monad: All components rely on the state monad: the parser (parser monad based on state monad), variable matching tables (more than one for internal types), identifier look up tables. And as these components all work together, they rely on the same state monad. Therefore there is a notion of state composition that brings together the different local states, and the notion of state accessors that give each algo their own state visibility. 

Initially, the design was really "just one big state monad". But then I started needing states with only local life times, and yet still in the context of the "persistent" state (and again, all these states are managed by state monads). For that I did need to introduce state monad transformers that augment the state and adapt the state monads together. I also added a transformer to move freely between a state monad and a continuation state monad but I have not bothered to use it.

Therefore, to answer the question: yes, monad transformers exist in the "wild". Yet I would argue strongly against using them "out of the box". Write your application with simple building blocks, using small hand crafted bridges between your modules, if you do end up using something like a monad transformer, that's great; Do not start from there.

And about the type signatures: I have come to think of this type of programming as something very similar to playing blindfold chess (and I am not a chess player): your skill level needs to be at the point that you "see" your functions and types fitting together. The type signatures mostly end up being a distraction, unless you explicitly want to add type constraints for safety reasons (or because the compiler forces you to give them such as with F# records).

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?

Has anyone ever encountered a Monad Transformer in the wild?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

在我的业务领域-金融机构的后台IT -软件组件携带全局配置，记录其进度，出现某种错误处理/计算短路，这是非常常见的……可以由Haskell中的Reader，Writer，或者可能是monad之类的东西很好地建模，并与monad transformers组合在一起。但似乎有一些缺点: monad转换器背后的概念相当棘手和...

问有没有人在野外遇到过Monad Transformer？
EN

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问有没有人在野外遇到过Monad Transformer？EN

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问有没有人在野外遇到过Monad Transformer？
EN