Talk:Referential transparency (computer science)

Benefits?

There should be some more detailed discussion of the possible benefits of referential transparency. For example, call-by-need is difficult to implement without it, as are many optimizations, such as memoization, and other code changes and refactorings.

Also, the use of the word 'enforced' seems strange to me. Perhaps 'guaranteed' would be better?

-- Mark Jason Dominus

It seems as though these suggestions have been accepted.

Examples

Wouldn't something like getTime() or random() be a better example for something that is free of side effects but not referential transparent?

Neither of those are free of side effects. Calling random() changes the number of times random() was called, thereby changing the output of the next occurrence. Calling getTime() takes time, thereby causing the next call to output a different value than it otherwise would have 174.134.202.24 (talk) 11:25, 1 October 2015 (UTC)

Problem with Assuming Imperative Model

Referential transparency may be meaningfully applied for behavior descriptions in reactive programming. today() might not be referentially transparent, since its value depends on one's time zone. However, time_GMT() can serve as referentially transparent because the behavior (continuously varying value) it references should be independent of referential context.

Incorrect

The description given in the article seems incorrect to me. Referential transparency is a property of a syntactic element, typically expressions, namely that elaboration of the expression results in the same value independently of location of the expression and time of evaluation. The property is assured if an expression is constructed entirely from constants and applications of pure functions. In particular, functions cannot be referentially transparent, only pure: it is the application of the function which may or may not be transparent.

Also the article describes an impure function which depends on a global variable, but doesn't clearly distinguish this case from a function with side-effects. The C construction termed a function may have side-effects on application, yet still its return value may depend only on its arguments. To account for this, I would use the adjective functional, meaning side-effect free. Referential transparency then depends on application of functions which are both functional and pure, or plainly said just "purely functional". The computer programming language Haskell claims to allow only the construction of purely functional function values, and thus all expressions in Haskell are referentially transparent.

Note that in some languages such as ML, functions are first class and can be passed as values, in this context an expression containing a function being passed as a value could be referentially transparent, even though the function itself depends on variables and has side-effects.

For this reason, the article is dangerously incorrect in attributing referential transparency to a 'function', since it fails to properly distinguish a value of a function type, from the application of such a value. In particular in Ocaml, there is no such thing as a function: equivalent constructions such as

let v = ref 0
let f x = print_endline "Hello"; x + !v
let f = fun x -> print_endline "Hello"; x + !v

are in fact both initialising f with a value of function type, and the expression

 f

is referentially transparent. The application

f 1

is certainly not transparent, and you might say that f is not pure or even functional, but you cannot say that f is not transparent because that is incorrect: the expression f is certainly transparent since it is a constant. In fact, the purity or functional nature of a 'function' refers to a value of function type, there is no such thing as a function in Ocaml, it uses a let-binding to construct values of function type.

In C there are functions, but this is a reference to a syntactic construction used to define a value of function pointer type.

All very tricky and technical, but the bottom line is that referential transparency is a semantic property of the syntactic element 'expression', not a property of a function, indeed it isn't even clear exactly what a 'function' is and the term is probably best avoided altogether in programming contexts.

--Skaller 03:19, 9 August 2005 (UTC)

This article has had some discussion on Lambda the Ultimate (http://lambda-the-ultimate.org/node/view/1237), where they also point out that the definition of on this page is inaccurate. I've tagged the article as having "disputed factual content", since that seemed to be the most appropriate template in Wikipedia:Template_messages. I'll try to improve the article soon, if nobody else does it first. -- Kimbly 23:57, 19 January 2006 (UTC)

There seems to be a better definition of referential transparency on the page about Functional Programming --Randomity 23:51, 21 March 2006 (UTC)

Still Incorrect

June 2010 - page still needs serious improvement!

Referential transparency requires that a symbolic reference have the same meaning in different contexts. 'System Administrator' is not referentially transparent because it means something different based on where it is used. 'Current Administrator of Wikipedia.org', on the other hand, means the same thing everywhere, even if said administrator changes over time.

• Referential transparency in a language constrains use of implicit local context, such as dynamic scoping. Functional purity, on the other hand, allows implicit, local contextual arguments (i.e. hidden monadic inputs), so long as there are no side-effects.

• Purity constrains effects, describing a system where the only effects of an expression are its local outputs. This allows a pure expression to be replaced by its result, subjected to lazy evaluation, and outright eliminated if the result proves unnecessary. Since there are no effects on 'time', pure expressions may be reordered and parallelized.

• Referentially transparent invocation semantics are not necessarily 'pure'. There is a vast gap between pure functional programming and imperative programming styles. In that gap lay impure declarative programming models, including reactive programming and concurrent constraint programming, where expressions may involve non-local effects yet still achieve many purity-like properties (determinacy, independence from ordering, idempotence). Further, one might also find a relationship to object-capability model and location transparency.

The distinction between 'RT' and 'purity' is unclear until you deal with a few of these less-than-mainstream paradigms.

Command-Query Separation

It seems to me that CQS is not concerned with referential transparency at all, but only with side effects. In the example given in the article, a read_integer command reads input from a file, and a last_integer query returns the value. This is not referentially transparent, because intervening calls to read_integer change the return from last_integer, despite its receiving the same arguments (it takes no arguments). Am I correct? 67.240.191.37 (talk) 02:33, 17 March 2009 (UTC)

removed disputation

I removed the disputation template for the main page because it seems like someone had updated the definition a while back to better reflect what true definition of Referential Transparency is thought to be.--Andrew Eisenberg 22:44, 8 August 2006 (UTC)

Wrong

The property that this page thinks it discusses has nothing to do with referential transparency. This article is discussing functional purity.

Referential transparency means that symbolic references to bindings are free from surprising interference in the face of code transformation. When the abstract syntax tree is rearranged so that new binding constructs are inserted in the path of the original reference, the bindings thus introduced are invisible to the established references.

Destructive manipulation of variables is perfectly consistent with referential transparency. The issue which affects referential transparency is not the manipulation itself, but rather which variable is manipulated.

Hygienic macros in Scheme are said to be referentially transparent, since a macro body can refer to lexical variables defined in its surrounding lexical scope without worry about capture by material that is inserted into the macro body from the macro arguments, or material that appears in the lexical scope of the site where the macro is expanded. —The preceding unsigned comment was added by 154.5.38.40 (talk) 02:55, 11 April 2007 (UTC).

Incomplete

This page sucks. It is seriously incomplete. It does not represent the use of the term referential transparency in any domain other than computing (and there are many others. Note that this article is a Category:Philosophy article). I even went so far as to add a lot of relevant content to the page on "Opaque Contexts" and redirected the page there, and was reverted. Weak. Last time I help this shithole website.38.100.212.21 (talk) 03:37, 21 November 2007 (UTC)

watcing

when someone is looking at somebody else —Preceding unsigned comment added by 77.99.132.139 (talk) 18:03, 27 February 2008 (UTC)

Eiffel IO example

The example saying that last_integer is referentially transparent is nonsense. By definition its value changes after each call to read_integer, ie. it depends on global state. —Preceding unsigned comment added by 89.103.110.62 (talk) 01:12, 19 January 2010 (UTC)