问题标签 [for-comprehension]

假设有两个函数findUser(id:String):Option[User]，findAddress(user:User):Option[Address]调用如下：

现在我想在此添加错误日志记录for-comprehension。如果找不到或找不到，我想调用一个log(msg:String)函数。useraddress

我可以在不更改函数签名的情况下做到这一点吗？

我在 Scala 编程第 23.5 节中读到，map、flatMap 和 filter 操作总是可以转换为 for-comprehensions，反之亦然。

我们得到以下等价物：

我有一个从一系列地图操作中计算出来的值：

我想知道这会是什么样的理解。我该如何翻译它？

（如果它有帮助，用文字来说是：

• 取 1 到 100 之间的整数
• 为每个，创建一个包含 100 个布尔值的列表
• 使用 XOR 运算符折叠每个列表，返回布尔值
• 根据布尔值产生 100 个字符串“打开”或“关闭”的列表

我想有一种标准的方法来翻译地图操作，其中实际功能的细节并不重要。不过我可能是错的。）

假设我有两个选项，如果两者都是 Some，则执行一个代码路径，如果注意，则执行另一个。我想做类似的事情

在if语句或模式匹配之外（如果我有两个以上的选项，可能无法扩展），有没有更好的方法来处理这个？

在 Python 中，我可以这样做：

这将需要一段时间，但内存使用量是恒定的。

scala中的相同构造：

过了一会儿，我得到了一个java.lang.OutOfMemoryError，即使它应该被懒惰地评估。

我刚刚发现自己编写了一段代码，如下所示：

如您所见，该值emaps是从字符串数组创建的双精度数组。它工作正常。我只是以前没有见过像这样嵌套的理解。可以吗，还是我应该以某种方式重构？

如果我用 Option 的值定义创建一个 for 理解，它会按预期工作：

如果我没有值定义，则使用 E​​ither 做同样的事情：

但是，如果我使用值定义，scala 似乎会为 for 理解推断错误的容器类型：

为什么这样做？有什么方法可以绕过这种行为？

为了便于理解，我不能只写一个打印语句：

但我可以通过虚拟分配轻松绕过它：

作为一个副作用，并且（到目前为止）仅用于正在开发的代码中，是否有更好的临时解决方案？

除了副作用之外，为什么我不应该使用它有什么严重的问题吗？

更新显示真实代码，其中适应一种解决方案比预期更难：

从与 Rex Kerr 的讨论来看，有必要展示原始代码，这有点复杂，但似乎与问题无关（2x .filter，最后调用一个方法），但是当我尝试将 Rex 的模式应用于它我失败了，所以我在这里发布：

这是我的尝试—— (b * a).filter 是错误的，因为结果是一个 int，而不是一个可过滤的 int 集合：

第二部分属于评论，但无法阅读，如果写在那里-也许我最后将其删除。请包涵。

好的 - 这是 Rex 在代码布局中的最后一个答案：

Learn You a Haskell教程有一个在列表理解中使用let活页夹的示例：

该函数接受一个身高/体重对的列表，并返回一个超出某个限制的相应体重指数的列表，例如：

对我来说有趣的是，在bmi理解中绑定的值既可以在守卫中使用，也可以在结果表达式中使用。我知道如何在 Scala 中做类似事情的唯一方法是编写：

不得不在Some这里包装我的价值感觉是错误的。有人知道更好的方法吗？

考虑：

现在我会写一个类似的方法：

但当然这不会编译，因为推断的类型是 Option[Option[Long]]。

在 scala 语法和标准库方面有没有办法获得 Option[Long]？我知道我可以进行模式匹配，但是刚刚出现了是否可以使用 for 理解来完成的问题。

感谢 Tenshi 的回答，这可以完成工作，但是我刚刚遇到了另一个问题示例：

我可以a在 for as 中添加：a <- Some(A(c))但是隐含的呢？这是否意味着我的代码中的设计更改？

给定一个数字与多个字符相关联的映射

我想根据数字序列生成所有可能的字符序列。例子：

我可以用理解来做到这一点

为每个索引创建一系列可能的字符

生成所有可能的字符序列

在这里事情变得丑陋，它只适用于三位数的序列。对于任何序列长度，有什么方法可以达到相同的结果吗？