编程中的引用透明性指的是，当一个函数提供了一个输入时，它总是会为给定的输入返回相同的值。以下面的示例函数为例。

Int plusFive(int x){

return x+5

}

对于给定的输入整数x，该函数总是返回相同的值。上述函数的输出可以被其返回值所替代，并且代码的操作应该相同。例如，如果x=10，那么代码可以写成:

Int输出= + 5 (10)

OR

Int输出= 15

当我读到被接受的答案时，我以为我在不同的页面上，而不是在stackoverflow上。

引用透明性是定义纯函数的一种更正式的方式。因此，如果一个函数在相同的输入上始终产生相同的结果，那么它就是引用透明的。

let counter=0
function count(){
  return counter++
}

这不是引用透明的，因为返回值取决于外部变量“counter”，并且它一直在变化。

这是我们如何使它的参考透明:

function count(counter){
       return counter+1
   }

现在这个函数是稳定的，并且在提供相同的输入时总是返回相同的输出。

引用透明函数是只依赖于其输入的函数。

[这是我3月25日的回答的后记，旨在使讨论更接近函数式/命令式编程的关注点。]

函数式程序员关于引用透明性的想法似乎在三个方面不同于标准的概念:

Whereas the philosophers/logicians use terms like "reference", "denotation", "designatum" and "bedeutung" (Frege's German term), functional programmers use the term "value". (This is not entirely their doing. I notice that Landin, Strachey and their descendants also used the term "value" to talk about reference/denotation. It may be just a terminological simplification that Landin and Strachey introduced, but it seems to make a big difference when used in a naive way.) Functional programmers seem to believe that these "values" exist within the programming language, not outside. In doing this, they differ from both the philosophers and the programming language semanticists. They seem to believe that these "values" are supposed to be obtained by evaluation.

例如，维基百科关于参考透明度的文章今天早上说:

如果一个表达式可以用它的值替换而不改变程序的行为(换句话说，在相同的输入上产生相同的效果和输出的程序)，那么这个表达式就是引用透明的。

This is completely at variance with what the philosophers/logicians say. They say that a context is referential or referentially transparent if an expression in that context can be replaced by another expression that refers to the same thing (a coreferential expression). Who are these philosophers/logicians? They include Frege, Russell, Whitehead, Carnap, Quine, Church and countless others. Each one of them is a towering figure. The combined intellectual power of these logicians is earth-shattering to say the least. All of them are unanimous in the position that referents/denotations exist outside the formal language and expressions within the language can only talk about them. So, all that one can do within the language is to replace one expression by another expression that refers to the same entity. The referents/denotations themselves do not exist within the language. Why do the functional programmers deviate from this well-established tradition?

有人可能会认为编程语言语义学家可能误导了他们。但是，他们没有。

Landin:

(a)每个表达式有一个 嵌套子表达式结构，(b)每个子表达式 表示某物(通常是数字、真值或 数值函数)，(c)表达式表示的东西， 也就是说，它的“值”只取决于它的子元素的值 表达式，而不是它们的其他属性。(添加重点)

Stoy:

关于表达式，唯一重要的是它的值，任何子表达式都可以 用其他同等价值的东西代替[强调]。此外，在一定范围内，表达式的值无论何时出现都是相同的。”

伯德和瓦德勒:

表达式的值仅取决于其组成部分的值 表达式(如果有)和这些子表达式可以被其他表达式自由替换 具有相同的价值[强调]。

So, in retrospect, the efforts of Landin and Strachey to simplify the terminology by replacing "reference"/"denotation" with "value" might have been injudicious. As soon as one hears of a "value", there is a temptation to think of an evaluation process that leads to it. It is equally tempting to think of whatever the evaluation produces as the "value", even though it might be quite clear that that is not the denotation. That is what I gather to have happened to the concept of "referential transparency" in the eyes of functional programmers. But the "value" that was being spoken of by the early semanticists is not the result of an evaluation or the output of a function or any such thing. It is the denotation of the term.

一旦我们将一个表达式(经典哲学家话语中的“引用”或“外延”)的所谓“价值”理解为一个复杂的数学/概念对象，各种可能性就会打开。

Strachey interpreted variables in imperative programming languages as L-values, as mentioned in my March 25 answer, which is a sophisticated conceptual object that does not have a direct representation within the syntax of a programming language. He also interpreted commands in such languages as state-to-state functions, another instance of a complex mathematical object that is not a "value" within the syntax. Even a side-effecting function call in C has a well-defined "value" as a state transformer that maps states to pairs of states and values (the so-called "monad" in functional programmers' terminology).

The reluctance of functional programmers to call such languages "referentially transparent" merely implies that they are reluctant to admit such complex mathematical/conceptual objects as "values". On the other hand, they seem perfectly willing to call a state transformer a "value" when it is put in their own favourite syntax and dressed up with a buzz word like "monad". I have to say that they are being entirely inconsistent, even if we grant it to them that their idea of "referential transparency" has some coherence.

A bit of history might throw some light on how these confusions came into being. The period between 1962 to 1967 was a very intensive one for Christopher Strachey. Between 1962-65, he took a part-time job as a research assistant with Maurice Wilkes to design and implement the programming language that came to be known as CPL. This was an imperative programming language but was meant to have powerful functional programming language capabilities as well. Landin, who was an employee of Strachey in his consultancy company, had a huge influence on Strachey's view of programming languages. In the landmark 1965 paper "Next 700 programming languages", Landin unabashedly promotes functional programming languages (calling them denotative languages) and describes imperative programming languages as their "antithesis". In the ensuing discussion, we find Strachey raising doubts on Landin's strong position.

．.． DLs形式 所有语言的子集。他们是一个有趣的子集，但只有一个 除非你习惯了，否则使用起来很不方便。我们需要 因为目前我们还不知道如何构造 使用包含命令和跳转的语言进行证明。(添加重点)

In 1965, Strachey took the position of a Reader at Oxford and seems to have worked essentially full-time on developing a theory of imperatives and jumps. By 1967, he was ready with a theory, which he taught in his course on "Fundamental concepts in programming languages" in a Copenhagen summer school. The lecture notes were supposed to have been published but "unfortunately, because of dilatory editing, the proceedings never materialized; like much of Strachey’s work at Oxford, however, the paper had an influential private circulation." (Martin Campbell-Kelly)

由于人们依赖二手资料和道听途说，很难获得斯特雷奇的作品可能会导致混淆的传播。但是，既然“基本概念”在网上很容易找到，就没有必要依靠猜测了。我们应该读一读，然后对斯特雷奇的意思作出自己的判断。特别是:

In section 3.2, he deals with "expressions" where he talks about "R-value referential transparency". His section 3.3 deals with "commands" where he talks about "L-value referential transparency". In section 3.4.5, he talks about "functions and routines" and declares that "any departure of R-value referential transparency in a R-value context should either be eliminated by decomposing the expression into several commands and simpler expressions, or, if this turns out to be difficult, the subject of a comment."

如果不理解l值、r值和其他填充命令式程序员概念宇宙的复杂对象之间的区别，任何关于“引用透明性”的讨论从根本上都是错误的。

引用透明性可以简单地表述为:

一个表达式在任何上下文中总是求相同的结果[1]， 一个函数，如果给定相同的参数两次，必须产生相同的结果两次。

例如，编程语言Haskell是一种纯函数式语言;这意味着它是引用透明的。

请注意，这个“意义”的概念是发生在观察者头脑中的事情。因此，同样的“参考”对不同的人可能意味着不同的事情。例如，我们在维基百科上有一个爱丁堡消歧页面。

在编程上下文中出现的一个相关问题可能是多态性。

也许我们应该为特殊情况下的多态(或者甚至是强制转换)取一个名字，其中不同的多态情况在语义上是等价的(而不是完全相似)。例如，数字1——可以用整数类型、复杂类型或任何其他类型表示——可以用多态方式处理)。