问题标签 [strictness]

以下

具有所需的短路特性False && undefined ≡ False。第一个子句在正确的参数中是非严格的，保证在尝试其他任何内容之前进行检查。

显然，如果我更改订单甚至取消功能，它仍然有效

但这实际上是由标准保证的吗？与子句的顺序不同，模式的评估顺序在这里不是很清楚。我真的可以确定在 snd 元素被评估之前，(True,False)一旦确定匹配就会被中止吗？(False,_)

我正在阅读有关严格数据构造函数的信息。链接的 Wiki 文章指出，

“严格性注释会使性能变差[因为]严格性注释会强制编译器确保在构建构造函数之前对该字段进行全面评估，如果事实证明该字段已被评估，那么这只是浪费工作”。

我不明白为什么如果该字段已经被评估它是浪费工作，因为无论如何都需要它的值来应用构造函数。

有没有一个例子来说明这个问题或其他由于严格而导致的效率损失？

我有一个f :: [a] -> b在无限列表上运行的函数（例如take 5，takeWhile (< 100) . scanl (+) 0等等）。我想为这个函数提供由严格的一元动作（例如randomIO）生成的值。

从这个问题中，我了解到repeatandsequence技巧方法不适用于严格的单子，如下面的示例所示：

所以，相反，我考虑在单子上下文“内部”使用函数。我受到这个循环编程示例的启发并尝试：

和

乃至

但这些都不起作用。我还尝试了Conduit一种即使在这种情况下也不起作用的方法Identity：

因此我想知道：

1. 为什么上面的“循环”方法都不起作用？

2. 如果存在不涉及的解决方案unsafeInterleaveIO。（也许iteratees，Arrows？）

据我所知，seq a b评估 (forces)a和b返回之前b。它不保证a首先评估。

pseq a b首先评估a，然后评估/返回b。

现在考虑以下几点：

函数应用程序需要先对左操作数求值（得到一个 lambda 形式），并且在进入函数之前不能盲目地求右操作数，因为这会违反 Haskell 的非严格语义。

因此(seq a id) b必须首先评估seq a id，它强制a和id（以某种未指定的顺序（但评估id什么都不做）），然后返回id b（即b）；因此在 之前xseq a b进行评估。ab

是xseq有效的实现pseq吗？如果不是，那么上述论点有什么问题（并且是否可以完全定义pseq）seq？

如果我们看containers包装。他们有Data.Map.Strict，但没有等价物Data.Set.Strict。它的存在有意义吗？

所以我有一个具有单个严格字段的​​存在数据类型：

使用（从这个答案unsafeSizeof偷来）的实验让我相信它可以是零内存开销：

所以看起来Uncurry有点像 a newtype，只在编译时使用。

这对我来说很有意义，因为平等断言不需要字典。

这是一个有效的解释吗？GHC（或 Haskell 报告）对此有任何保证，还是我只是运气好？

In other words, can the following be optimized to Just [1..]?

There is also a more specific example in data61/fp-course where early termination is expected iff an Empty value is present.

Why does changing order of the first two patterns make function loop forever as if Empty cannot be ever matched? I vaguely understand that such definition would make f strict in the infinite list, but I don't see what is actually causing this.

Or are these unrelated problems?

Side question: does it matter that stack is exhausted and not heap?

我正在读这篇文章。上面写着：

当用记录语法构造一个值时，如果你忘记了一个严格的字段，GHC 会给你一个错误。它只会给你一个非严格字段的​​警告。

谁能给我一个具体的例子吗？

Haskell 模式匹配通常是严格的，例如，f (x:xs) = ... 需要将输入列表评估为（thunk : thunk）。但有时不需要这样的评估，并且函数可以对某些参数不严格，例如f (x:xs) = 3.

理想情况下，在这种情况下，我们可以避免评估参数以获得 的行为const 3，这可以通过无可辩驳的模式来完成：f ~(x:xs) = 3. 这给我们带来了性能优势和更大的容错能力。

我的问题是：GHC 是否已经通过某种严格分析实现了这种转换？如果您也可以指出我的一些读物，请不胜感激。

我正在尝试对使用递归数据类型的函数进行基准测试（使用Criterion ）。我发现了一个类似的问题，但我无法申请我的案子。对于非递归数据类型，以下工作：

但是，执行以下操作：

在我希望进行基准测试的函数上调用nf函数时会导致错误，该函数具有以下签名：Criterion.MaintestFunction :: (Show a1, Integral a1, Num a2, Eq a2) => [[a1]] -> ExampleDataType3 a2 a1

对于如何全面评估递归数据类型，我将不胜感激。

编辑1：

导致错误的基准调用：

该函数testFunction根据需要完成其工作，但我未能完全评估递归数据类型，以便nfCriterion 的函数可以接受我的函数作为输入。因此，我想避免更改数据类型。