问题标签 [referential-transparency]

我们知道纯函数：

1. 始终为给定输入返回相同的结果
2. 不产生副作用

这使我们实现了引用透明性——在不改变程序行为的情况下，可以将表达式替换为值。

这告诉我们，如果一个程序排除了程序运行环境中实体的破坏性修改（更新），则可以说它是纯功能性的。

当我们查看软件事务内存时，我们看到了一种类似于数据库事务的并发控制机制，用于控制并发计算中对共享内存的访问。但这本身并没有什么特别的功能。

我的问题是：我们可以考虑 Clojure 的 STM '功能'吗？

Erlang 中的单一赋值如何导致代码更具可读性（引用透明性）？

在我的另一个问题之后，我尝试使用 Idris for实现类型驱动开发same_cons中的实际练习，以证明给定两个相等的列表，将相同的元素添加到每个列表会导致两个相等的列表。

例子：

prove that 1 :: [1,2,3] == 1 :: [1,2,3]

所以我想出了以下编译代码：

我可以通过以下方式调用它：

关于cong函数，我的理解是它需要一个证明，即a = b，但我不明白它的第二个参数：f a.

请解释。

问题

假设我有一些只有引用透明函数的编程语言。众所周知，这些函数中的任何一个都可以被记忆。然而，记忆函数在时间或空间方面并不总是值得的。决定自动记忆函数是否会节省空间或时间的算法是什么？

例子

我的用例

我有一个 Lisp 解释器作为副项目，它将自身限制为 Lisp 的纯功能子集。我想记忆函数，但我不想盲目地决定应该记忆什么，不应该记忆什么。

附加信息

该解决方案可以使用静态代码分析运行，也可以在程序的生命周期内运行，或者可以在程序的多次运行中运行。

解决方案不一定是完美的；它可能只是一种启发式方法，在很多时候都是正确的。

要将 IO 函数添加到用 Haskell 编写的编程语言解释器中，我基本上有两种选择：

• 修改整个解释器以在 IO monad 内部运行
• 让解释程序可以调用的运行时函数使用unsafePerformIO.

前者对我来说是个坏主意——这实际上抵消了程序中几乎所有地方的任何 纯度优势。IO我目前也ST大量使用，并且必须修改大量程序才能实现这一点，因为我看不到同时使用两者ST（IO？）。

后者让我感到紧张——正如函数名称所述，它是不安全的，但我认为在这种情况下它可能是合理的。特别：

• 此更改涉及的代码量将非常少。
• 可以执行 IO 的点已经通过在seq解释表达式求值期间使用 at 控制点来显式排序。
• 或许更重要的是，IO 操作返回的值只会在代码的解释部分中使用，我可以通过解释器不能使用相同的参数多次调用这一事实来保证引用透明性，因为操作计数器将通过线程整个系统作为同一更改的一部分，并且始终以唯一值传递给将使用unsafePerformIO.

在这种情况下，有充分的理由不使用unsafePerformIO吗？

更新

有人问我为什么要保持口译员的纯洁性。原因有很多，但也许最紧迫的是我打算以后为这种语言构建一个编译器，该语言将包含各种元编程技术，这些技术将要求编译器包含解释器，但我想成为能够保证编译结果的纯度。为此目的，该语言将有一个纯子集，我希望解释器在执行该子集时是纯的。

这可能接近哲学，但我认为这是问的正确地方。

假设我有一个创建 ID 列表的函数。这些标识符仅在应用程序内部使用，因此Symbol()这里使用 ES2015 是可以接受的。

我的问题是，从技术上讲，当您要求一个符号时，我想 JS 运行时会创建一个唯一标识符（随机数？内存地址？不确定），为了防止冲突，需要访问全局状态。我不确定的原因是因为“技术上”这个词。我不确定（再次从哲学的角度来看）这是否足以打破 API 呈现的数学抽象。

tl;博士：这是一个例子——

这个函数是纯的吗？

因此，我正在尝试学习 FP，并且正在尝试了解引用透明度和副作用。

我了解到，在类型系统中明确显示所有效果是保证引用透明性的唯一方法：

“主要是函数式编程”的想法是不可行的。仅通过部分消除隐式副作用来使命令式编程语言更安全是不可能的。留下一种效果通常足以模拟您刚刚尝试删除的效果。另一方面，允许在纯语言中“忘记”效果也会以自己的方式造成混乱。

不幸的是，没有黄金中间，我们面临着一个经典的二分法：排中间的诅咒，它提供了以下两种选择：(a) 尝试使用纯度注释来驯服效果，但完全接受这样一个事实，即您的代码是仍然基本有效；或（b）通过在类型系统中明确所有效果并务实来完全接受纯度 -来源

我还了解到像 Scala 或 F# 这样的非纯 FP 语言不能保证引用透明性：

强制引用透明性的能力与 Scala 拥有与 Java 可互操作的类/对象系统的目标非常不兼容。-来源

而在非纯 FP 中，由程序员来确保引用透明性：

在 ML、Scala 或 F# 等非纯语言中，确保引用透明性取决于程序员，当然在 Clojure 或 Scheme 等动态类型语言中，没有静态类型系统来强制引用透明性。-来源

我对 F# 很感兴趣，因为我有 .Net 背景，所以我的下一个问题是：

如果 F# 编译器不强制执行，我可以做些什么来保证 F# 应用程序中的引用透明性？

我刚刚发布了这段代码：

我的理由是unsafeThaw在这里使用它是安全的，因为我只indexed解冻xs. 然而，后来我突然想到，元组的未装箱向量——就像这里的这些索引值对——实际上存储为两个未装箱的向量，一个用于索引，一个用于值。indexed因此，实际上根本不会生成新的值向量，而只是将它与索引向量结合起来，这似乎是合理的。在这种情况下，ST-modifyingxsi可能会搞砸xs。

经测试，这似乎并没有发生。我可以依靠这个，还是应该更好地使用thaw？

抱歉这里有新问题，但是 Haskell 怎么知道不对 eg 应用引用透明性，readLn或者当putStrLn两次 -ing 相同的字符串时？是因为IO涉及吗？IOW，编译器不会对返回的函数应用引用透明性IO吗？

我目前正在编写有关函数式编程的演示文稿，并遇到了以下问题。

函数式编程旨在将“什么”与“如何”分开，或者更准确地说，将计算的声明与其解释分开。这就是为什么这种范式的主要焦点之一是使用可组合的数据结构来表示计算，而不对它们的执行方式做出任何假设。例如：

这似乎是有道理的，因为副作用应该只在计算执行期间而不是在其声明期间执行。问题在于，在 Scala 中，许多数据结构似乎违反了这条规则：

同样适用于Futures：

所以，我现在想知道，是否Try真的Future是参照透明的？如果不是，那么应该如何在不依赖Successand的情况下处理错误情况Failure？