Scala中for-comprehension的补救语法问题

Question

我在Scala 2.10中遇到for-comprehension的语法问题.

for(a <- List(Some(1,2)); b <- a) yield b 评估为 List(1,2)

那么为什么不for(a <- Some(List(1,2)); b <- a) yield b评价同样的东西呢？

类型检查器抱怨第二个表达式(b <-a)说它List[Int] 在期待时找到了Option[?]

Answer 1

我最近解释过这个 - 希望有人能找到这个链接.这是一个反复出现的问题,所以很可能会被关闭.

无论如何,外部发电机控制表示.这发生在每个级别,所以如果我有这个:

for { 
  a <- A
  b <- B
  c <- C
} yield f(a, b, c)

然后表示f(a, b, c)由其控制C,其表示由控制B,并且最终结果的表示由控制A.因此,对于大多数实际目的,理解的表示由第一生成器控制.

那么"代表"是什么意思呢？好了,对于理解是一个单子的理解,通常(实际上,它只是一组来电来样方法flatMap和map,因此它可以是任何东西是typechecks).这意味着,给定一个单子M[A]和一个功能A => M[B],那么你可以改变M[A]的M[B],在那里M,单子,是"代表".

这意味着,在大多数情况下,组合Option和List理解都是不可能的.所有的集合都有一个共同的父级GenTraversableOnce,所以组合它们没有问题(虽然事情比引擎下的要复杂得多).

然而,从隐式转换Option到Iterable.既然如此,当Scala b <- a在第一个例子中找到它并且知道它不能通过一个Option因为理解被a"控制"时List,它就会转换Option成一个Iterable,并且一切正常.

但是,在第二种情况下不会发生这种情况.用a进行理解是Option可以的,所以没有必要将它转换为Iterable.不幸的是,人们无法将a List转换为Option(这种转换的结果是什么？),这会导致错误.

Scala不会"回溯" a <- Some(List(1, 2))并对其应用隐式转换,因为Scala中的类型推断只会前进 - 它之前决定的将保持不变.

我衷心建议您查看相关问题,并了解如何翻译理解.