函数式编程中纯函数的缺点[关闭]

Question

函数式编程中的纯函数是没有副作用的函数。 其中一个含义是它不能改变输入参数的值。 这可以被视为内存利用的缺点吗？
例如，假设我有一个函数，它只需要一个列表并在其中添加另一个元素。 在C ++中，它可以很简单

void addElem(std::vector& vec, int a)
{
    vec.insert(a);
}

这个函数显然没有使用传递对象已经占用的大量内存。
但在Haskell中也会出现类似的情况。

addElem :: [Int] -> Int -> [Int] 
addElem xs a = xs ++ [a]

现在在这个计算中，因为xs没有改变它的值。 所以我说的是，在某些时候，该函数将消耗xs的内存双倍大小，一个用于xs，另一个用于返回值。 或者以某种方式延迟调用确保实际xs只通过在末尾添加一个元素才能返回？
我知道Monad是一种可以产生副作用的方法。 但Monad可以用来简单地修改输入并返回它的值吗？
也可以将xs ++ [a]更改为：xs消耗更少的内存？

Answer 1

纯度意味着该函数不能进行破坏性更新，所以如果

xs ++ [a]

完全评估，必须制作xs的副本。 如果xs是懒惰地生成并且没有在其他任何地方引用，那么这可能发生在恒定空间中，因此它可以在创建时进行垃圾收集。 或者除了xs之外它还需要一个副本 - 但纯度允许两个列表的单元格指向相同的数据，因此不需要复制数据，只需要复制脊椎（由最终的缺点修改）。 但是如果制作副本，旧值xs仍然可用。

也可以将xs ++ [a]更改为：xs消耗更少的内存？

是的，那个可以简单地重用xs ，所需要的只是创建一个新的列表单元格并让它的尾部指针指向xs 。

来自评论：

我不希望C ++函数是纯粹的。 我希望它改变输入的状态。 这就是我想成为问题的重点。

在这种情况下，您需要一个不纯的功能/动作。 对于某些数据结构来说，这是可能的，但对于列表，必须重新复制/构造单元。 但是向std::vector<T>添加元素可能还需要重新分配。

Answer 2

是的，纯FP可能比命令式编程更耗费内存，但这取决于您编写程序的方式以及编译器的智能程度。 特别是Haskell编译器具有非常强大的优化器，并且可能能够将纯FP代码转换为重用已分配内存的高效机器代码。 这需要编写好的FP代码，因为即使是最聪明的编译器也不会包含优化来处理仅使用表面上类似的FP结构模拟命令式的程序。

请注意，您的C ++示例无效。 如果你的意思

v[0] = a;  // assuming v.size() > 0

然后，这不做任何分配。 如果你的意思

v.append(a);

那么可能会也可能不会分配，具体取决于v的容量。

或者以某种方式延迟调用确保实际xs只通过在末尾添加一个元素才能返回？

取决于表达式在其上下文中的实现和使用。 当xs ++ [a]被完全评估时，它会复制整个列表xs 。 如果对其进行部分评估，则可以在none和len(xs)之间进行任意数量的分配。

也可以将xs ++ [a]更改为：xs消耗更少的内存？

是的，这将它从O（n）最坏情况改为O（1）最坏情况分配/额外内存使用。 同样适用于时间复杂性。 在Haskell中处理列表时，永远不要追加到最后。 如果这是您需要的，请使用差异列表 。

Answer 3

我认为你的两个例子之间的相关差异是数据结构的选择，而不是纯粹与不纯的问题。

您可以在两种方法中使用单个链接列表，并且可以在两者中使用具有恒定时间更新的阵列。 在纯粹的情况下，对数据结构的更新可以在语义上进行复制，但这并不一定意味着它在物理上这样做。

例如，Ropes是不可变数组的变体，允许恒定时间连接。 您还可以通过在内部使用写时复制方案来实现具有恒定时间功能更新的不可变数组抽象（其中a.set（i，x）在语义上返回副本），如果您实际访问该方案，则仅执行物理副本创建新版本之后的旧版本（即，如果您使用纯数据结构的持久性功能，这在不纯的情况下是不可用的）。

Answer 4

ab·strac·tion [ab-strak-shuh n]

除了具体的现实，特定的对象或实际情况之外，将某事视为一般品质或特征的行为。

交易

平衡所有这些因素无法同时实现

漏洞抽象

在某种程度上，所有非平凡的抽象都是漏洞。

函数式编程可以看作是一种抽象，并且由于所有抽象都会泄漏，因此需要进行一些权衡。

Answer 5

现在在这个计算中，因为xs没有改变它的值。 所以我说的是，在某些时候，该函数将消耗xs的内存双倍大小，一个用于xs，另一个用于返回值。

不必要。 拥有不可变数据的优点是可以共享。 因此编译器可以通过在这种情况下共享x来进行优化。 所以大小将与c ++的大小相同。

或者以某种方式延迟调用确保实际xs只通过在末尾添加一个元素才能返回？

懒惰只是意味着在实际需要值时进行评估，它不能保证更少的内存使用量。 另一方面，由于懒惰而创建的thunk可能会使用更多内存。

我知道Monad是一种可以产生副作用的方法。 但Monad可以用来简单地修改输入并返回它的值吗？

你是部分正确的。 Monad用于组成具有副作用的代码。 您可以很好地使用可变向量并编写与IO monad中的c ++示例非常相似的代码。

也可以将xs ++ [a]更改为：xs消耗更少的内存？

这是依赖于编译器的，但我认为它会复制整个列表并在最后添加元素。 （我不是这方面的专家）。

您可以随时分析代码并检查内存消耗，这是了解此问题的最佳方法。

Answer 6

不同的语言有不同的共同习语，实施者努力使这些习语尽可能有效。 我不会认为因为某些东西需要额外的C ++开销，在另一种语言中也是如此，就像我不认为另一种语言中最有效的习语在C ++中最有效。

话虽如此：我目前正在开发一个大型，高性能的应用程序，我们经常返回std::vector ，我们没有发现这是一个问题。 像NRVO和移动语义这样的东西最终意味着这在C ++中也非常有效。