Ya no busques más por internet porque has llegado al lugar necesario, contamos con la solución que quieres recibir pero sin complicarte.
Solución:
El término “transparencia referencial” proviene de la filosofía analítica, la rama de la filosofía que analiza las construcciones, declaraciones y argumentos del lenguaje natural basados en los métodos de la lógica y las matemáticas. En otras palabras, es la asignatura más cercana fuera de la informática a lo que llamamos semántica de los lenguajes de programación. El filósofo Willard Quine fue el encargado de iniciar el concepto de transparencia referencial, pero también estuvo implícito en los planteamientos de Bertrand Russell y Alfred Whitehead.
En esencia, la “transparencia referencial” es una idea muy simple y clara. El término “referente” se utiliza en filosofía analítica para hablar de la cosa a la que se refiere una expresión. Es más o menos lo mismo que queremos decir con “significado” o “denotación” en la semántica del lenguaje de programación. Usando el ejemplo de Andrew Birkett (entrada de blog), el término “la capital de Escocia” se refiere a la ciudad de Edimburgo. Ese es un ejemplo sencillo de un “referente”.
Un contexto en una oración es “referencialmente transparente” si se reemplaza un término en ese contexto por otro término que se refiere a la misma entidad no altera el significado. Por ejemplo
El Parlamento escocés se reúne en la capital de Escocia.
significa lo mismo que
El Parlamento escocés se reúne en Edimburgo.
Así que el contexto “El Parlamento escocés se reúne en …” es un contexto referencialmente transparente. Podemos reemplazar “la capital de Escocia” por “Edimburgo” sin alterar el significado. Dicho de otra manera, al contexto solo le importa a qué se refiere el término y nada más. Ese es el sentido en el que el contexto es “referencialmente transparente”.
Por otro lado, en la oración,
Edimburgo es la capital de Escocia desde 1999.
no podemos hacer tal reemplazo. Si lo hiciéramos, obtendríamos “Edimburgo ha sido Edimburgo desde 1999”, lo cual es una locura decirlo, y no transmite el mismo significado que la oración original. Entonces, parecería que el contexto “Edimburgo ha sido … desde 1999” es referencialmente opaco (lo opuesto a referencialmente transparente). Aparentemente se preocupa por algo más de lo que se refiere el término. ¿Qué es?
Cosas como “la capital de Escocia” se llaman términos definidos y durante mucho tiempo no les dieron dolor de cabeza a los lógicos y filósofos. Russell y Quine los clasificaron diciendo que en realidad no son “referenciales”, es decir, es un error pensar que los ejemplos anteriores se utilizan para referirse a entidades. La forma correcta de entender “Edimburgo ha sido la capital de Escocia desde 1999” es decir
Escocia tiene una capital desde 1999 y esa capital es Edimburgo.
Esta frase no se puede transformar en una locura. ¡Problema resuelto! El punto de Quine era decir que el lenguaje natural es desordenado, o al menos complicado, porque está hecho para ser conveniente para el uso práctico, pero los filósofos y los lógicos deberían aportar claridad al comprenderlos de la manera correcta. La transparencia referencial es una herramienta que se utilizará para llevar claridad de significado.
¿Qué tiene que ver todo esto con la programación? En realidad, no mucho. Como dijimos, la transparencia referencial es una herramienta para ser utilizada en la comprensión del lenguaje, es decir, en la asignación sentido. Christopher Strachey, quien fundó el campo de la semántica del lenguaje de programación, lo usó en su estudio del significado. Su artículo fundacional “Conceptos fundamentales en lenguajes de programación” está disponible en la web. Es un artículo hermoso y todos pueden leerlo y entenderlo. Así que, por favor, hágalo. Estarás muy iluminado. Introduce el término “transparencia referencial” en este párrafo:
Una de las propiedades más útiles de las expresiones es la que Quine llama transparencia referencial. En esencia, esto significa que si deseamos encontrar el valor de una expresión que contiene una subexpresión, lo único que necesitamos saber acerca de la subexpresión es su valor. Cualquier otra característica de la subexpresión, como su estructura interna, el número y la naturaleza de sus componentes, el orden en que se evalúan o el color de la tinta en la que están escritas, son irrelevantes para el valor de la principal expresión.
El uso de “en esencia” sugiere que Strachey lo está parafraseando para explicarlo en términos simples. Los programadores funcionales parecen entender este párrafo a su manera. Hay otras 9 apariciones de “transparencia referencial” en el documento, pero no parecen preocuparse por ninguna de las otras. De hecho, todo el artículo de Strachey está dedicado a explicar el significado de lenguajes de programación imperativos. Pero, hoy, los programadores funcionales afirman que los lenguajes de programación imperativos son no referencialmente transparente. Strachey estaría revolcándose en su tumba.
Podemos salvar la situación. Dijimos que el lenguaje natural es “desordenado, o al menos complicado” porque está hecho para ser conveniente para un uso práctico. Los lenguajes de programación son de la misma manera. Son “desordenados, o al menos complicados” porque están hechos para ser convenientes para un uso práctico. Eso no significa que deban confundirnos. Solo tienen que entenderse de la manera correcta, utilizando un metalenguaje que sea referencialmente transparente para que tengamos claridad de significado. En el artículo que cité, Strachey hace exactamente eso. Explica el significado de los lenguajes de programación imperativos dividiéndolos en conceptos elementales, sin perder nunca la claridad en ninguna parte. Una parte importante de su análisis es señalar que las expresiones en los lenguajes de programación tienen dos tipos de “valores”, llamados valores l y valores r. Antes del artículo de Strachey, esto no se entendía y reinaba la confusión. Hoy en día, la definición de C lo menciona de forma rutinaria y todos los programadores de C comprenden la distinción. (Es difícil decir si los programadores en otros lenguajes lo entienden igualmente bien).
Tanto Quine como Strachey estaban preocupados por el significado de las construcciones del lenguaje que implican alguna forma de dependencia del contexto. Por ejemplo, nuestro ejemplo “Edimburgo ha sido la capital de Escocia desde 1999” significa el hecho de que “capital de Escocia” depende del momento en que se la considere. Tal dependencia del contexto es una realidad, tanto en lenguajes naturales como en lenguajes de programación. Incluso en la programación funcional, las variables libres y ligadas deben interpretarse con respecto al contexto en el que aparecen. La dependencia del contexto de cualquier tipo bloquea la transparencia referencial de una forma u otra. Si intenta comprender el significado de los términos sin tener en cuenta los contextos de los que dependen, volverá a terminar confundido. A Quine le preocupaba el significado de la lógica modal. Sostuvo que la lógica modal era referencialmente opaca y debería limpiarse traduciéndola a un marco referencialmente transparente (por ejemplo, considerando la necesidad como demostrabilidad). Perdió en gran medida este debate. Tanto los lógicos como los filósofos encontraron que la posible semántica del mundo de Kripke era perfectamente adecuada. Una situación similar también reina con la programación imperativa. La dependencia del estado explicada por Strachey y la dependencia de la tienda explicada por Reynolds (de una manera similar a la posible semántica mundial de Kripke) son perfectamente adecuadas. Los programadores funcionales no conocen mucho de esta investigación. Sus ideas sobre la transparencia referencial deben tomarse con gran esmero.
[Additional note: The examples above illustrate that a simple phrase such as “capital of Scotland” has multiple levels of meaning. At one level, we might be talking about the capital at the current time. At another level, we might talking about all possible capitals that Scotland might have had through the course of time. We can “zoom into” a particular context and “zoom out” to span all contexts quite easily in normal practice. The efficiency of natural language makes use of our ability to do so. Imperative programming languages are efficient in very much the same way. We can use a variable x on the right hand side of an assignment (the r-value) to talk about its value in a particular state. Or, we might talk about its l-value which spans all states. People are rarely confused by such things. However, they may or may not be able to precisely explain all the layers of meaning inherent in language constructs. All such layers of meaning are not necessarily ‘obvious’ and it is a matter of science to study them properly. However, the inarticulacy of ordinary people to explain such layered meanings doesn’t imply that they are confused about them.]
Una “posdata” separada a continuación relaciona esta discusión con las preocupaciones de la programación funcional e imperativa.
La transparencia referencial, un término comúnmente utilizado en la programación funcional, significa que dada una función y un valor de entrada, siempre recibirá la misma salida. Es decir, no se utiliza ningún estado externo en la función.
A continuación, se muestra un ejemplo de una función transparente referencial:
int plusOne(int x)
return x+1;
Con una función transparente referencial, dada una entrada y una función, podría reemplazarla con un valor en lugar de llamar a la función. Entonces, en lugar de llamar a plusOne con un parámetro de 5, podríamos reemplazarlo con 6.
Otro buen ejemplo son las matemáticas en general. En matemáticas, dada una función y un valor de entrada, siempre se correlacionará con el mismo valor de salida. f (x) = x + 1. Por lo tanto, las funciones en matemáticas son referencialmente transparentes.
Este concepto es importante para los investigadores porque significa que cuando tiene una función referencialmente transparente, se presta a una fácil paralelización automática y almacenamiento en caché.
La transparencia referencial se utiliza siempre en lenguajes funcionales como Haskell.
–
En contraste, existe el concepto de opacidad referencial. Esto significa lo contrario. Es posible que llamar a la función no siempre produzca el mismo resultado.
//global G
int G = 10;
int plusG(int x)
//G can be modified externally returning different values.
return x + G;
Otro ejemplo es una función miembro en un lenguaje de programación orientado a objetos. Las funciones miembro normalmente operan en sus variables miembro y, por lo tanto, serían referencialmente opacas. Las funciones de los miembros, aunque, por supuesto, pueden ser referencialmente transparentes.
Otro ejemplo más es una función que lee un archivo de texto e imprime la salida. Este archivo de texto externo podría cambiar en cualquier momento, por lo que la función sería referencialmente opaca.
Una función referencialmente transparente es aquella que solo depende de su entrada.
Comentarios y puntuaciones del tutorial
Al final de todo puedes encontrar las referencias de otros sys admins, tú incluso tienes la opción de insertar el tuyo si te gusta.