Kleisli, ReaderT, Reader 在Scalaz中是一样的难道只是巧合吗 [英] Is it just a coincidence that Kleisli, ReaderT, and Reader are the same in Scalaz

查看:58
本文介绍了Kleisli, ReaderT, Reader 在Scalaz中是一样的难道只是巧合吗的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

在 Scalaz 中

  • Kleisli[F, A, B]A => 的包装器.F[B].
  • ReaderT[F, A, B] -- 阅读器 monad 转换器 -- 只是 Kleisli[F, A, B] 的别名.
  • Reader[A, B] monad 是 ReaderT 的特化,具有标识 monad Id:
    type Reader[A, B] = ReaderT[Id, A, B].
  • Kleisli[F, A, B] is a wrapper for A => F[B].
  • ReaderT[F, A, B] -- reader monad transformer -- is just an alias of Kleisli[F, A, B].
  • Reader[A, B] monad is a specialization of ReaderT with identity monad Id:
    type Reader[A, B] = ReaderT[Id, A, B].

KleisliReaderTReader 是巧合还是有一些更深层的原因Scalaz 中的同构?

Is it just a coincidence or there are some deeper reasons that Kleisli, ReaderT, and Reader are isomorphic in Scalaz ?

推荐答案

你可以把它想象成通过两条不同的路线到达同一个地方.一方面,您从 reader monad 开始,它只是一种函数的包装器.然后您意识到您想将此阅读器功能集成到具有其他效果"的更大 monad 中,因此您创建了一个 ReaderT monad 转换器.在这一点上,将您的原始 Reader[E, ?] 实现为 ReaderT[Id, E, ?] 是有意义的.

You can think of it as arriving at the same place by two different routes. On one side you start with the reader monad, which is simply a kind of wrapper for functions. Then you realize that you want to integrate this reader functionality into a larger monad with other "effects", so you create a ReaderT monad transformer. At that point it makes sense to implement your original Reader[E, ?] as ReaderT[Id, E, ?].

另一方面,您需要一个类型来表示 Kleisli 箭头(即具有一元返回类型的函数).事实证明,这与 ReaderT 是一回事,所以您只需将其设为别名即可.

From the other side, you want a type to represent Kleisli arrows (i.e. functions with a monadic return type). It turns out that this is the same thing as ReaderT, so you just make that an alias.

结果证明"部分并没有什么特别神秘的地方.这有点像如果你开始使用 Addable 类型类来处理类似数字的事情,然后决定让它更通用,最终得到一个只提供关联加法"的类型类像"操作.你彻底改造了Semigroup!不过,出于历史或教学原因,或者只是为了方便,您可能仍希望保留 Addable 名称.

There's nothing terribly mysterious about the "it turns out" part. It's a little like if you started out with an Addable type class for number-like things, then decide to make it more generic, and eventually end up with a type class that just provides an associative "addition-like" operation. You've reinvented Semigroup! You may still want to keep the Addable name around, though, for historical or pedagogical reasons, or just for convenience.

这就是 ReaderReaderT 发生的所有事情——您不需要需要这些别名,但它们很方便,并且可能会有所帮助提高代码的清晰度.

That's all that's happening with Reader and ReaderT—you don't need these aliases, but they can be convenient, and may help improve the clarity of your code.

这篇关于Kleisli, ReaderT, Reader 在Scalaz中是一样的难道只是巧合吗的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆