F# 中的工作流构建器不使用接口是否有原因？
这是出于好奇而提出的问题：当您实现工作流工厂时，您不会将其作为接口实现来执行，而只是确保 monad 函数的函数签名匹配。这有设计原因吗？
This is a question just out of curiosity: when you implement a workflow factory, you don't do it as an interface implementation, but rather just make sure the function signatures of the monad functions match. Is there a design reason for this?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
一方面，.NET 中缺乏更高级的类型意味着您无法为这些方法提供有用的签名。例如，
ListBuilder.Return应该具有类型't -> 't list，而OptionBuilder.Return的类型应为't ->; 't选项。无法使用Return方法创建具有支持这两种方法的签名的接口。For one thing, the lack of higher-kinded types in .NET means that you can't give the methods useful signatures. For instance,
ListBuilder.Returnshould have type't -> 't list, whileOptionBuilder.Returnshould have type't -> 't option. There's no way to create an interface with aReturnmethod that has a signature supporting both of these methods.我认为 kvb 提到的缺乏更高级的类型可能是主要原因。有多种方法可以解决这个问题，但这会使代码有点晦涩（请参阅此代码段）。
另一个原因是 F# 计算表达式允许您定义不同的方法组合。它并不总是只是
Bind和Return。例如：Yield、YieldFrom、Combine以允许生成结果Return、ReturnFrom,Bind定义一个 monadReturn,ReturnFrom,Bind,Combine定义一个可以返回多个东西的 monadDelay或Delay和Run来处理懒惰......所以计算表达式需要定义为很多不同的接口。我认为当前的设计在您可以支持的计算功能方面留下了一些很好的灵活性。
I think that the lack of higher-kinded types as mentioned by kvb is probably the main reason. There are ways to workaround that, but that makes the code a bit obscure (see this snippet).
Another reason is that F# computation expressions allow you to define different combinations of methods. It's not always just
BindandReturn. For example:Yield,YieldFrom,Combineto allow generating resultsReturn,ReturnFrom,Bindto define a monadReturn,ReturnFrom,Bind,Combineto define a monad that can return multiple thingsDelayorDelayandRunto handle laziness... so computation expressions would need to be defined as quite a few different interfaces. I think the current design leaves some nice flexibility in what features of computations you can support.