你把monad里面的数据称为什么？

Question

在演讲和写作中,我一直想要参考monad中的数据,但我不知道该怎么称呼它.

例如,在Scala中,传递给函数的参数flatMap被绑定到......呃...... monad中的那个东西.在:

List(1, 2, 3).flatMap(x => List(x, x))

x 受到限制,我没有一句话.

稍微复杂一点,传递给Kleisli箭头的参数不一定会绑定到monad中的所有数据.与List,Set,Stream,和许多其它的单子,flatMap调用Kleisli箭头很多次,结合x到单子内每次不同片数据.或者甚至不是"数据",只要遵循monad法则.无论它是什么,它都包裹在monad中,并flatMap在没有包装的情况下传递给你,也许一次一件.我只是想知道什么叫做相关的内部monad内容,x至少在某种程度上,所以我可以阻止所有这些愚蠢的语言.

这个东西/数据/价值/东西/无论它是什么标准或传统术语？

如果没有,"糖果"怎么样？

Answer 1

试图说" x被束缚"会让你失败.让我解释一下,并指导你在谈论这些事情时更好地表达自己.

假设我们有:

someList.flatMap(x => some_expression)

如果我们知道someList有类型List[Int],那么我们可以有把握xInt地说some_expression内部绑定了一个type类型的值.注意警告,"some_expression内部".这是因为,考虑到someList = List(1,2,3),x将在他们每个人的价值观:1,2,和3,反过来.

考虑一个更通用的例子:

someMonadicValue.flatMap(x => some_expression)

如果我们一无所知someMonadicValue,那么我们对如何some_expression被调用知之甚少.它可以运行一次,或三次(如上例所示),或者懒洋洋地,或者异步运行,或者可以安排一次someMonadicValue完成(例如,期货),或者它可能永远不会被使用(例如空列表,无).Monad接口不包括关于何时或如何someExpression使用的推理.所以你所能说的x将是什么,仅限于上下文some_expression,无论何时,无论如何 some_expression被评估.

回到这个例子.

someMonadicValue.flatMap(x => some_expression)

你试图说" x是???的someMonadicValue." 而你正在寻找准确替换???的词.好吧,我在这里告诉你,你做错了.如果你想谈论x,那么要么这样做

1. 在上下文中some_expression.在这种情况下,使用我在上面给出的粗体短语:"some_expression内部,x绑定到类型的值Foo." 或者,您也可以谈论x......
2. 了解您正在处理哪个monad.

例如,对于#2,someList.flatMap(x => some_expression)你可以说" x是每个元素someList." 因为someFuture.flatMap(x => some_expression),你可以说" 如果它真的能够完成并取得成功,那么它是x未来成功的价值someFuture".

你看,这就是Monads的美丽.那??? 你试图描述的是Monad接口抽象的东西.现在你明白为什么这么难给？一个名字？这是因为它对每个特定的monad都有不同的名称和不同的含义.这就是拥有Monad抽象的要点:在同一计算界面下统一这些不同的概念.

Answer 2

免责声明：我绝对不是函数式编程术语方面的专家，我希望以下内容不会从您的角度回答您的问题。对我来说，问题在于：如果选择一个术语需要专业知识，那么理解也需要专业知识。

选择合适的术语很大程度上取决于：

• 您期望的语言正确性水平，以及
• 您的受众以及某些术语的相应含义。

关于语言正确性，问题是您是否正确地想要引用绑定到的值/数据x，或者您是否可以接受某种（不正确的）抽象。就受众而言，我主要区分具有扎实的函数式编程背景的受众和来自其他编程范式的受众。对于前者，选择术语可能并不完全重要，因为概念本身很熟悉，并且许多术语会导致正确的关联。评论中的讨论已经包含了针对此案例的一些非常好的建议。但是，讨论还表明您需要一定的函数式编程背景才能了解某些术语背后的基本原理。

对于没有函数式编程背景的观众，我宁愿为了可理解性而牺牲语言的正确性。在这种情况下，我经常将其称为“底层类型”，只是为了避免我可能通过尝试引用“单子中的事物”本身而造成的任何混乱。x显然，“绑定到底层类型”的说法从字面上来说是错误的。然而，对我来说更重要的是我的听众完全理解一个概念。由于大多数程序员都熟悉容器及其底层类型，因此我的目标是（有缺陷的）关联“底层类型”=>“容器中的事物”=>“容器内的事物” monad”，这似乎经常有效。

TL;DR：正确性和可访问性之间总是需要权衡。当谈到函数式编程时，有时将偏见转向后者会有所帮助。