【问题标题】:Is it just a coincidence that Kleisli, ReaderT, and Reader are the same in ScalazScalaz 中的 Kleisli、ReaderT 和 Reader 是一样的只是巧合吗
【发布时间】:2015-03-24 06:52:20
【问题描述】:

在 Scalaz 中

  • Kleisli[F, A, B]A => F[B] 的包装器。
  • ReaderT[F, A, B] -- reader monad 转换器 -- 只是Kleisli[F, A, B] 的别名。
  • Reader[A, B] monad 是 ReaderT 的特化,具有身份 monad Id:
    type Reader[A, B] = ReaderT[Id, A, B]

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

【问题讨论】:

  • Reader 和 ReaderT/Kleisli 不是同构的(如你所说,前者是后者的特化)。
  • @ZhekaKozlov 谢谢。我错了(虽然不会更新问题)。

标签: scala scalaz reader-monad kleisli


【解决方案1】:

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

另一方面,您想要一个表示 Kleisli 箭头的类型(即具有一元返回类型的函数)。原来这和ReaderT是一回事,所以你把它设为别名就好了。

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

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

【讨论】:

猜你喜欢
  • 2011-02-03
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2019-08-17
  • 2023-03-30
  • 2017-04-26
  • 2010-11-15
  • 2021-07-15
相关资源
最近更新 更多