¿Qué es la transparencia referencial?

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 hay estado externo utilizado en la función.

Aquí hay 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. Así que 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 asignará al 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 se tiene una función referencialmente transparente, se presta a una fácil paralelización automática y almacenamiento en caché.

La transparencia referencial se usa siempre en lenguajes funcionales como Haskell.

--

En contraste está el concepto de opacidad referencial. Esto significa lo contrario. Llamar a la función puede no siempre producir la misma salida.

//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 comúnmente operan en sus variables miembro y, por lo tanto, serían opacas referenciales. Funciones del miembro aunque puede de por supuesto ser referencialmente transparente.

Otro ejemplo es una función que lee desde 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.

[Esta es una posdata de mi respuesta del 25 de marzo, en un esfuerzo por acercar la discusión a las preocupaciones de la programación funcional/imperativa.]

La idea de transparencia referencial de los programadores funcionales parece diferir de la noción estándar de tres maneras:

• Mientras que los filósofos / lógicos usan términos como" referencia"," denotación"," designatum "y" bedeutung "(término alemán de Frege), los programadores funcionales usan el término"valor". (Este no es enteramente su obra. Noto que Landin, Strachey y sus descendientes también usaron el término "valor" para hablar de referencia/denotación. Puede ser solo una simplificación terminológica que Landin y Strachey introdujeron, pero parece hacer una gran diferencia cuando se usa de una manera ingenua.)

• Los programadores funcionales parecen creer que estos" valores " existen dentro del lenguaje de programación, no fuera. Al hacer esto, difieren tanto de los filósofos como de la semanticistas del lenguaje de programación.

• Ellos parecen creer que estos" valores " se supone que se obtienen por evaluación.

Por ejemplo, el artículo de Wikipedia sobre transparencia referencial dice, esta mañana:

Se dice que una expresión es referencialmente transparente si se puede reemplazar con su valor sin cambiar el comportamiento de un programa (en otras palabras, produciendo un programa que tiene los mismos efectos y salida en el mismo entrada).

Esto está completamente en desacuerdo con lo que dicen los filósofos/lógicos. Dicen que un contexto es referencial o referencialmente transparente si una expresión en ese contexto puede ser reemplazada por otra expresiónque se refiere a la misma cosa (una coreferencial expresión). Quiénes son estos filósofos/lógicos? Ellos incluyen Frege, Russell, Whitehead, Carnap, Quine, la Iglesia y incontables otros. Cada uno de ellos es una figura imponente. El poder intelectual combinado de estos lógicos es devastador, por decir lo menos. Todos ellos son unánimes en la posición de que los referentes / denotaciones existen fuera del lenguaje formal y las expresiones dentro del lenguaje solo pueden hablar sobre ellos. Por lo tanto, todo lo que uno puede hacer dentro del lenguaje es reemplazar una expresión por otra expresión que se refiere a la misma entidad. Los referentes/denotaciones mismos hacen no existen dentro del lenguaje. ¿Por qué los programadores funcionales se desvían de esta tradición bien establecida?

Uno podría suponer que los semanticistas del lenguaje de programación podrían haberlos engañado. Pero, no lo hicieron.

Landin:

(a) cada expresión tiene un estructura de subexpresión de anidamiento, (b) cada subexpresión denota algo (generalmente un número, valor de verdad o función numérica) , (c) la cosa que denota una expresión, i. e., su "valor", depende solo de los valores de su sub- expresiones, no en otras propiedades de ellas. [Énfasis añadido]

Stoy:

Lo único que importa de una expresión es su valor, y cualquier subexpresión puede ser sustituido por cualquier otro valor igual [Subrayado añadido]. Además, el valor de una expresión es, dentro de ciertos límites, el mismo siempre que ocurre".

Bird and Wadler :

El el valor de una expresión depende solo de los valores de su componente expresiones (si las hay) y estas subexpresiones pueden ser reemplazadas libremente por otras poseer el mismo valor [Énfasis añadido].

Así que, en retrospectiva, los esfuerzos de Landin y Strachey para simplificar la terminología reemplazando "referencia"/"denotación" con "valor" podrían haber sido imprudentes. Tan pronto como uno oye hablar de un "valor", hay una tentación de pensar en un proceso de evaluación que conduce a se. Es igualmente tentador pensar en lo que la evaluación produce como el "valor", aunque podría ser bastante claro que esa no es la denotación. Eso es lo que deduzco que le ha pasado al concepto de "transparencia referencial" a los ojos de los programadores funcionales. Pero el" valor " del que hablaban los primeros semanticistas es no el resultado de una evaluación o la salida de una función o cualquier cosa semejante. Es la denotación del término.

Una vez que entender el llamado "valor"de una expresión ("referencia "o" denotación " en el discurso de los filósofos clásicos) como un objeto matemático/conceptual complejo, abre todo tipo de posibilidades.

• Strachey interpretó variables en lenguajes de programación imperativos como valores L , como mencioné en mi respuesta del 25 de marzo, que es un objeto conceptual sofisticado que no tiene una representación directa dentro de la sintaxis de un lenguaje de programación.
• Él también comandos interpretados en lenguajes tales como funciones de estado a estado, otra instancia de un objeto matemático complejo que no es un "valor" dentro de la sintaxis.
• Incluso una llamada a función de efecto lateral en C tiene un "valor" bien definido como un transformador de estado que asigna estados a pares de estados y valores (la llamada "mónada" en la terminología de los programadores funcionales).

La renuencia de los programadores funcionales a llamar a tales lenguajes "referencialmente transparentes" meramente implica que son reacios a admitir objetos matemáticos / conceptuales tan complejos como"valores". Por otro lado, parecen perfectamente dispuestos a llamar a un transformador de estado un "valor" cuando se pone en su propia sintaxis favorita y se viste con una palabra de moda como "mónada". Tengo que decir que están siendo totalmente inconsistentes, incluso si les concedemos que su idea de "transparencia referencial" tiene cierta coherencia.

Un poco de historia podría arrojar algo de luz sobre cómo estos surgieron confusiones. El período entre 1962 y 1967 fue muy intenso para Christopher Strachey. Entre 1962-65, tomó un trabajo a tiempo parcial como asistente de investigación con Maurice Wilkes para diseñar e implementar el lenguaje de programación que llegó a ser conocido como CPL. Landin, que era un empleado de Strachey en su empresa de consultoría, tuvo una gran influencia en Strachey la vista de los lenguajes de programación. En el histórico documento de 1965 "Next 700 programming languages", Landin promueve descaradamente los lenguajes de programación funcionales (llamándolos lenguajes denotativos) y describe los lenguajes de programación imperativos como su "antítesis". En la discusión subsiguiente, encontramos que Strachey plantea dudas sobre la fuerte posición de Landin.

... Formulario DLs un subconjunto de todos los idiomas. Son un subconjunto interesante, pero uno que es incómodo de usar a menos que esté acostumbrado. Necesitamos porque en este momento no sabemos cómo construir pruebas con lenguajes que incluyen imperativos y saltos. [Énfasis añadido]

En 1965, Strachey tomó la posición de lector en Oxford y parece haber trabajado esencialmente a tiempo completo en el desarrollo de una teoría de imperativos y saltos. En 1967, estaba listo con una teoría, que enseñó en su curso sobre " Conceptos fundamentales en la programación languages" in a Copenhagen summer school. Se suponía que las notas de la conferencia habían sido publicadas, pero "desafortunadamente, debido a la dilatoria edición, los procedimientos nunca se materializaron; como gran parte del trabajo de Strachey en Oxford, sin embargo, el el periódico tenía una influyente circulación privada."( Martin Campbell-Kelly )

La dificultad de obtener los escritos de Strachey podría haber llevado a que las confusiones se propagaran, con la gente confiando en fuentes secundarias y rumores. Pero, ahora que " Conceptos fundamentales " está fácilmente disponible en la web, no hay necesidad de recurrir a conjeturas. Deberíamos leerlo y decidir qué quería decir Strachey. En particular:

• En la sección 3.2, trata de "expresiones" donde habla de "transparencia referencial del valor R".
• Su sección 3.3 trata de "comandos" donde habla de "transparencia referencial del valor L".
• En la sección 3.4.5, habla de "funciones y rutinas "y declara que" cualquier desviación de la transparencia referencial de valor-R en un contexto de valor-R debería o bien se eliminará descomponiendo la expresión en varios comandos y más simple expresiones, o, si esto resulta ser difícil, el tema de un comentario."

Cualquier charla de "transparencia referencial" sin entender la distinción entre valores-L, valores-R y otros objetos complejos que pueblan el universo conceptual del programador imperativo es fundamentalmente equivocado.

Una expresión es referencialmente transparente si puede ser reemplazada por su valor, sin cambiar el algoritmo, produciendo un algoritmo que tiene los mismos efectos y salida en la misma entrada.

Una función referencialmente transparente es aquella que actúa como una función matemática; dadas las mismas entradas, siempre producirá las mismas salidas. Implica que el estado pasado no está modificado, y que la función no tiene estado propio.

Si usted está interesado en la etimología (es decir. ¿por qué este concepto tiene este nombre en particular), echa un vistazo a mi entrada de blog sobre el tema. La terminología proviene del filósofo/lógico Quine.

Para aquellos que necesitan una explicación concisa, arriesgaré una (pero lea la divulgación a continuación).

La transparencia referencial en un lenguaje de programación promueve el razonamiento ecuacional the cuanta más transparencia referencial tenga, más fácil es hacer el razonamiento ecuacional. Por ejemplo, con una definición de función (pseudo),

F x = x + x,

La facilidad con la que puede reemplazar (de forma segura) f (foo) con foo + foo en el alcance de esta definición, sin tener demasiadas restricciones en dónde puede realizar esta reducción, es una buena indicación de cuánta transparencia referencial tiene su lenguaje de programación.

Por ejemplo, si foo fuera x++ en el sentido de programación en C, entonces no podría realizar esta reducción de forma segura (es decir, si realizara esta reducción no terminaría con el mismo programa con el que comenzó).

En los lenguajes de programación prácticos no verás una transparencia referencial perfecta, pero a los programadores funcionales les importa es más que la mayoría (cf Haskell, donde es un objetivo central).

(Revelación completa: Soy un programador funcional así que por la respuesta superior usted debe tomar esta explicación con un grano de sal.)

1. La semántica denotacional se basa en lenguajes de modelado mediante la construcción de dominios que constituyen valores denotables .
2. Los programadores funcionales usan el término valor para describir la convergencia de un cálculo basado en las reglas de reescritura del lenguaje ie. su semántica operativa.

En 1 hay una claridad de dos idiomas en cuestión:

• el que está siendo modelado, el lenguaje objeto
• el lenguaje del modelado, el meta idioma

En 2, gracias a la cercanía del objeto y los metalenguajes, pueden confundirse.

Como implementador de lenguaje, encuentro que necesito recordar constantemente esta distinción.

Así que el Prof. Reddy me permite parafrasearlo así: -)

En los contextos de programación funcional y semántica, el término Referencial Transparency no es referencialmente transparente.

Note que este concepto de "significado" es algo que sucede en la mente del observador. Por lo tanto, la misma "referencia" puede significar diferentes cosas para diferentes personas. Así, por ejemplo, tenemos una página de desambiguación de Edimburgo en Wikipedia.

Un problema relacionado que puede aparecer en el contexto de la programación podría ser el polimorfismo.

Y tal vez deberíamos tener un nombre para el caso especial de polimorfismo (o tal vez incluso fundición) donde para nuestros propósitos las diferencias los casos polimórficos son semánticamente equivalentes (en lugar de ser simplemente similares. Por ejemplo, el número 1 which que podría ser representado usando un tipo entero, o un tipo complejo o cualquiera de una variedad de otros tipos can puede ser tratado polimórficamente).

La siguiente respuesta espero que se suma y califica la polémica 1ª y 3ª respuesta.

Concedamos que una expresión denota o se refiere a algún referente. Sin embargo, una pregunta es si estos referentes pueden ser codificados isomórficamente como parte de las propias expresiones, llamándolas "valores". Por ejemplo, los valores numéricos literales son un subconjunto del conjunto de expresiones aritméticas, los valores de verdad son un subconjunto del conjunto de expresiones booleanas, etc. La idea es evaluar una expresión a su valor (si tiene uno). Por lo tanto, la palabra 'valor' puede referirse a una denotación o a un elemento distinguido del conjunto de expresiones. Pero si hay un isomorfismo (una biyección) entre el referente y el valor se puede decir que son la misma cosa. (Dicho esto, hay que tener cuidado de definir los referentes y el isomorfismo, como lo demuestra el campo de la denotación semántica. Para poner un ejemplo mencionado por las respuestas a la 3a respuesta, el definición de tipo de datos algebraicos data Nat = Zero | Suc Nat no corresponden como se espera al conjunto de números naturales.)

Escribamos E[·] para una expresión con un agujero, también conocida en algunos sectores como un 'contexto'. Dos ejemplos de contexto para expresiones similares a C son [·]+1 y [·]++.

Escribamos [[·]] para la función que toma una expresión (sin agujero) y entrega su significado (referente, denotación, etc. en algunos universo que proporciona significado. (Estoy tomando prestada la notación del campo de semántica denotacional.)

Let nosotros adaptamos la definición de Quine de la siguiente manera: un contexto E[·] is referentially transparent iff given any two expressions E1 and E2 (no holes hay) tal que [[E1]] = [[E2]] (es decir, las expresiones denotan / se refieren-a la el mismo referente) entonces es el caso de que [[E[E1]]] = [[E[E2]]] (es decir, el agujero con E1 o E2 resulta en expresiones que también denotan lo mismo referent).

La regla de Leibniz de sustituir iguales por iguales se expresa típicamente como ' si E1 = E2 entonces E[E1] = E[E2]', que dice que E[·] es una función. Función (o para el caso un programa que calcula la función) es una asignación de un fuente a un destino de modo que haya como máximo un elemento de destino para cada fuente elemento. Las funciones no deterministas son nombres incorrectos, son relaciones, funciones entregando conjuntos, etc. Si en la regla de Leibniz la igualdad = es denotacional a continuación, los corchetes dobles simplemente se dan por sentado y elided. Así que un contexto referencialmente transparente es una función. Y La regla de Leibniz es el ingrediente principal del razonamiento ecuacional, por lo que el razonamiento ecuacional está definitivamente relacionado con la transparencia referencial.

Aunque [[·]] es una función de expresiones a denotaciones, podría ser una función de expresiones a' valores ' entendidos como un subconjunto restringido de expresiones, y [[·]] se pueden entender como evaluación.

Ahora, si E1 es una expresión y E2 es un valor, tenemos lo que creo que significa la mayoría de la gente al definir referencial transparencia en términos de expresiones, valores y evaluación. Pero como lo ilustran las respuestas 1ª y 3ª en esta página, esta es una definición imprecisa.

El problema con contextos como [·]++ no es el efecto secundario, sino que su valor no está definido en C isomórficamente a su significado. Las funciones son no valores (bueno, punteros a funciones son) mientras que en lenguajes de programación funcionales son. Landin, Strachey, y los pioneros de la semántica denotacional fueron bastante inteligentes en usando mundos funcionales para proporcionar significado.

Para lenguajes imperativos como C podemos (aproximadamente) proporcionar semántica a expresiones usando la función [[·]] : Expression -> (State -> State x Value).

Value es un subconjunto de Expression. State contiene pares (identificador,valor). La función semántica toma una expresión y entrega como su significado una función del estado actual al par con el actualizado estado y un valor. Por ejemplo, [[x]] es la función del estado actual a la pareja cuyo primer componente es el estado actual y cuyo segundo componente es el valor de x. En contraste, [[x++]] es la función de la estado actual del par cuyo primer componente es un estado en el que el valor de x se incrementa, y cuyo segundo componente es ese mismo valor. En este sentido, el contexto [·]++ es referencialmente transparente si satisface el definición dada anteriormente.

Creo que los programadores funcionales tienen derecho a utilizar la transparencia referencial en la sensación de que naturalmente se recuperan [[·]] como una función de expresiones a valores. Las funciones son valores de primera clase y el estado también puede ser un valor, no un denotación. La mónada de estado es (en parte) un mecanismo limpio para pasar (o threading) el estado.

En programación funcional, la transparencia referencial se define generalmente como el hecho de que una expresión, en un programa, puede ser reemplazada por su valor (o cualquier cosa que tenga el mismo valor) sin cambiar el resultado del programa. Esto implica que los métodos siempre deben devolver el mismo valor para un argumento dado, sin tener ningún otro efecto. Sin embargo, este concepto de programación funcional también se aplica a la programación imperativa y puede ayudarlo a crear su código más claro.

Transparencia Referencial

La expresión transparencia referencial se usa en varios dominios, como matemáticas, lógica, lingüística, filosofía y programación. Tiene significados muy diferentes en cada uno de estos dominios. Aquí, trataremos solo con programas de computadora, aunque mostraremos analogía con las matemáticas (matemáticas simples, no te preocupes). Tenga en cuenta, sin embargo, que los científicos de la computación no están de acuerdo en el significado de la transparencia referencial en la programación. Lo veremos si la transparencia referencial es utilizada por programadores funcionales.

Transparencia Referencial en Matemáticas En matemáticas, la transparencia referencial es la propiedad de expresiones que pueden ser reemplazadas por otras expresiones que tengan el mismo valor sin cambiar el resultado de ninguna manera. Considere el siguiente ejemplo:

x = 2 + (3 * 4)

Podemos reemplazar la subexpresión (3 * 4) con cualquier otra expresión que tenga el mismo valor sin cambiar el resultado (el valor de x). La mayoría la expresión evidente a utilizar, es por supuesto 12:

x = 2 + 12

Cualquier otra expresión que tenga el valor 12 (maybe (5 + 7)) podría usarse sin cambiar el resultado. Como consecuencia, la subexpresión (3 * 4) es referencialmente transparente.

También podemos reemplazar la expresión 2 + 12 por otra expresión que tenga el mismo valor sin cambiar el valor de x, por lo que también es referencialmente transparente:

x = 14

Se puede ver fácilmente el beneficio de la transparencia referencial: Permite razonamiento. Sin ella, no podríamos resolver ninguna expresión sin considerar algunos otros elementos.

Transparencia Referencial en la Programación En la programación, la transparencia referencial se aplica a los programas. Como los programas están compuestos de subprogramas, que son programas en sí mismos, también se aplica a esos subprogramas. Los subprogramas pueden estar representados, entre otras cosas, por métodos. Eso significa que el método puede ser referencialmente transparente, que es el caso si una llamada a este método puede ser reemplazada por su valor de retorno:

int add(int a, int b) {
        return a + b
    }

int mult(int a, int b) {
        return a * b;
    }

int x = add(2, mult(3, 4));

En este ejemplo, el método mult es referencialmente transparente porque cualquier llamada a él puede ser reemplazada por el valor devuelto correspondiente. Esto se puede observar reemplazando mult (3, 4) con 12:

int x = add(2, 12)

De la misma manera, add(2, 12) puede ser reemplazado por el valor de retorno correspondiente, 14:

int x = 14;

Ninguno de estos reemplazos cambiará el resultado del programa, haga lo que haga. Nótese que podríamos usar cualquier otra expresión que tenga la misma valor, que es útil al refactorizar.

Por otro lado, considere el siguiente programa:

int add(int a, int b) {
    int result = a + b;
    System.out.println("Returning " + result);
    return result;
}

Reemplazar una llamada al método add con el valor devuelto correspondiente cambiará el resultado del programa, ya que el mensaje ya no se imprimirá. En ese caso, solo eliminaría el efecto secundario, pero en otros casos, podría cambiar el valor devuelto por el método:

public static void main(String... args) {
    printFibs(10);
}

public static void printFibs(int limit) {
    Fibs fibs = new Fibs();
    for (int i = 0; i < limit; i++) {
        System.out.println(fibs.next());
    }
}

static class Fibs {
    private int previous = -1;
    private int last = 1;

    public Integer next() {
        last = previous + (previous = last);
        return previous + last;
    }
}

Aquí, el siguiente método no se puede reemplazar con nada que tenga el mismo valor, ya que el método está diseñado para devolver un valor diferente en cada llamada.

El uso de tales métodos no referencialmente transparentes requiere una fuerte disciplina para no compartir el estado mutable involucrado en el cálculo. El estilo funcional evita tales métodos en favor de versiones referencialmente transparentes.

Transparencia Referencial en la Programación Imperativa Tanto la programación imperativa como la funcional utilizan funciones. Aunque la programación funcional utiliza solo funciones, imperativo usos de programación:

• funciones puras: métodos que devuelven valores y no tienen otros efectos
• efectos puros: métodos que no devuelven nada más que cambiar algo fuera de ellos)
• funciones con efectos secundarios: métodos que devuelven un valor y cambiando algo

Como todos sabemos, es una buena práctica evitar las funciones con efectos secundarios. Esto deja a los programadores imperativos con funciones puras y efectos puros. La transparencia referencial es entonces un herramienta poderosa para que los programadores imperativos hagan sus programas más fáciles de razonar y más fáciles de probar.