Qu'est-ce que la transparence référentielle ?

Question

Que signifie le terme transparence référentielle C'est-à-dire ? J'ai entendu dire que cela signifiait "que l'on peut remplacer les égaux par des égaux", mais cela semble être une explication inadéquate.

Answer 1

Le terme "référentiel de transparence" vient de la philosophie analytique, la branche de la philosophie qui analyse en langage naturel des constructions, des déclarations et des arguments fondés sur les méthodes de la logique et des mathématiques. En d'autres termes, il est le plus proche de l'objet à l'extérieur de l'informatique à ce que nous appelons le langage de programmation sémantique. Le philosophe Quine a été chargé de lancer le concept de la transparence référentielle, mais il est également implicite dans les approches de Bertrand Russell et Alfred Whitehead.

À la base, le "référentiel de la transparence" est très simple et claire idée. Le terme "référence" est utilisé dans la philosophie analytique de parler de la chose que l'expression se réfère. Il est à peu près la même chose que ce que nous entendons par "sens" ou de "dénotation" dans le langage de programmation sémantique. À l'aide de Andrew Birkett de l'exemple (billet de blog), le terme "la capitale de l'Ecosse" se réfère à la ville d'Edimbourg. C'est un exemple simple de "référence".

Un contexte dans une phrase est "referentially transparent" si le remplacement d'un terme dans ce contexte par un autre terme qui fait référence à la même entité ne pas modifier le sens. Par exemple

Le Parlement Écossais se réunit dans la capitale de l'Ecosse.

signifie la même chose que

Le Parlement Écossais répond à Edimbourg.

De sorte que le contexte "Le Parlement Écossais se réunit en ..." est un referentially cadre transparent. Nous pouvons remplacer "la capitale de l'Ecosse" avec "Édimbourg" sans en altérer le sens. Mettre une autre manière, le contexte se soucie uniquement de ce que le terme se réfère à et rien d'autre. C'est le sens dans lequel le contexte est "referentially transparent."

En revanche, dans la phrase,

Edimbourg est la capitale de l'Écosse depuis 1999.

nous ne pouvons pas faire ce remplacement. Si nous le faisions, nous serions "Édimbourg a été Edimbourg depuis 1999", qui est une noisette chose à dire, et ne rend pas le même sens que la phrase d'origine. Il semblerait donc que le contexte "d'Edimbourg a été ... depuis 1999" est referentially opaque (à l'opposé de referentially transparent). Apparemment, il se soucie de quelque chose de plus que ce que le terme se réfère. Quel est-il?

Des choses comme "la capitale de l'Ecosse" sont appelés des conditions qui sont définies et ils n'ont donné aucune maigre quantité de maux de tête pour les logiciens et les philosophes depuis un long moment. Russell et Quine triées en disant qu'ils ne sont pas réellement "référentiel", c'est à dire, c'est une erreur de penser que la sont utilisés pour se référer à des entités. La bonne façon de comprendre la phrase ci-dessus est-à-dire

L'ecosse a eu un capital depuis 1999 et que le capital est d'Édimbourg.

Cette phrase ne peut pas être transformée en une noisette. Problème résolu! Le point de Quine est-à-dire que le langage naturel est en désordre, ou au moins compliquée, car il est fait pour être pratique pour un usage pratique, mais les philosophes et les logiciens devrait apporter de la clarté par la compréhension dans le droit chemin. La transparence référentielle est un outil à utiliser pour parvenir à la clarté du sens.

Est-ce que tout cela a à voir avec la programmation? Pas beaucoup, en fait. Comme nous l'avons dit, la transparence référentielle est un outil à utiliser dans la compréhension de la langue, c'est à dire, dans l'attribution de sens. Christopher Strachey, qui a fondé le domaine du langage de programmation sémantique, l'a utilisée dans son étude de la signification. Son fondateur papier "concepts Fondamentaux des langages de programmation" est disponible sur le web. C'est un beau papier et tout le monde peut le lire et le comprendre. Donc, merci de le faire. Vous serez beaucoup éclairé. Il introduit le terme "référentiel de transparence" dans ce paragraphe:

L'un des plus utiles propriétés des expressions est appelé par Quine [4] référentielle de la transparence. En substance, cela signifie que si nous voulons trouver la valeur d'une expression qui contient une sous-expression, la seule chose que nous avons besoin de savoir à propos de la sous-expression est sa de la valeur. Toutes les autres caractéristiques de la sous-expression, telles que sa structure interne, le nombre et la nature de ses composants, l'ordre dans lequel ils sont évalués ou la couleur de l'encre dans laquelle ils sont écrits, ne sont pas pertinents à la valeur de l'expression principale.

L'utilisation du "essence" suggère que Strachey est de la paraphrase dans le but d'expliquer en termes simples. Fonctionnelle programmeurs semblent comprendre ce paragraphe dans leur propre chemin. Il y a 9 autres occurrences de "référentiel de transparence" dans le papier, mais ils ne semblent pas se préoccuper de tous les autres. En fait, l'ensemble du document de Strachey est consacrée à l'explication du sens de l' impératif langages de programmation. Mais, aujourd'hui, fonctionnelle programmeurs demande que l'impératif de langages de programmation sont pas referentially transparent. Strachey serait retourner dans sa tombe.

Nous pouvons sauver la situation. Nous avons dit que le langage naturel est "bordélique, ou au moins compliquée" parce qu'il est fait pour être pratique pour un usage pratique. Les langages de programmation sont de la même manière. Ils sont "en désordre, ou au moins compliquée" car elles sont faites pour être pratique pour un usage pratique. Cela ne signifie pas qu'ils ont besoin de nous confondre. Ils ont juste à être compris le droit chemin, à l'aide d'un méta-langage qui est referentially transparent, de sorte que nous avons la clarté du sens. Dans le document que j'ai cité, Strachey est exactement ce que fait. Il explique la signification de la programmation impérative langues en les décomposant en concepts élémentaires, en ne perdant jamais de clarté n'importe où. Une partie importante de son analyse est de mettre en évidence que les variables dans les langages de programmation ont deux sortes de "valeurs", appelé l-valeurs et r-valeurs. Avant de Strachey, du papier, ce n'était pas compris et la confusion régnait en maître. Aujourd'hui, la définition de C mentionne régulièrement et chaque programmeur C comprend la distinction. (Si les programmeurs dans d'autres langues le comprendre aussi bien est difficile à dire.)

Les deux Quine et Strachey, étaient préoccupés par le sens de la langue des constructions qui impliquent une certaine forme de contexte de dépendance. Par exemple, notre "Edimbourg est la capitale de l'Écosse depuis 1999" signifie le fait que "la capitale de l'Ecosse" dépend de l'heure à laquelle il est envisagé. Ce contexte, la dépendance est une réalité, à la fois dans les langues naturelles et langages de programmation. Même dans la programmation fonctionnelle, libre et liée variables doivent être interprétés en ce qui concerne le contexte dans lequel ils apparaissent. Contexte de la dépendance de tout type de blocs de transparence référentielle, d'une certaine façon ou de l'autre. Si vous essayez de comprendre le sens des termes, sans égard aux contextes qu'ils dépendent de l', vous serait à nouveau jusqu'à la fin avec confusion. Quine était préoccupé par le sens de la logique modale. Il a jugé que la logique modale a été referentially opaque et il doit être nettoyé en le traduisant dans un referentially cadre transparent (par exemple, en considérant l'état de nécessité comme provability). Il a largement perdu de ce débat. Les logiciens et les philosophes semblables trouvé Kripke de monde possible sémantique être parfaitement adéquat. Situation similaire a également règne avec la programmation impérative. L'état de dépendance explique par Strachey et stockez-la dépendance explique par Reynolds (d'une manière similaire à Kripke est possible mot "sémantique") sont parfaitement adéquates. Fonctionnelle programmeurs ne savent pas beaucoup de cette recherche. Leurs idées sur la transparence référentielle sont à prendre avec un gros grain de sel.

[Remarque: Les exemples ci-dessus montrent que dans une phrase simple comme "la capitale de l'Ecosse" a plusieurs niveaux de sens. À un certain niveau, on peut parler de la capitale, à l'heure actuelle. À un autre niveau, on peut parler de tous les possibles capitales que l'Ecosse pourrait avoir eu à travers le temps. On peut "zoomer" dans un contexte particulier et "zoom arrière" pour étendre à tous les contextes assez facilement dans la pratique normale. L'efficacité de la langue naturelle rend l'utilisation de notre capacité à le faire. Impératif de langages de programmation sont efficaces dans beaucoup de la même manière. Nous pouvons utiliser une variable x sur le côté droit de cession ( valeur r) pour parler de sa valeur dans un état particulier. Ou, nous pourrions parler de sa l-valeur qui s'étend à tous les états. Les adultes sont rarement confus par ce genre de choses. Cependant, ils peuvent ou peuvent ne pas être en mesure d'expliquer toutes les couches de sens inhérente au langage des constructions. Toutes ces couches de sens ne sont pas forcément évidentes et c'est une question de science pour étudier correctement. Cependant, la inarticulacy des gens ordinaires pour expliquer de telles couches de significations ne signifie pas qu'ils sont confus au sujet de eux.]

Un "post-scriptum" ci-dessous se rapporte à cette discussion pour les préoccupations fonctionnelles et de programmation impératif.

Answer 2

La transparence référentielle, un terme couramment utilisé dans la programmation fonctionnelle, signifie qu'avec une fonction et une valeur d'entrée, vous recevrez toujours la même sortie. En d'autres termes, aucun état externe n'est utilisé dans la fonction.

Voici un exemple de fonction transparente référentielle :

int plusOne(int x)
{
  return x+1;
}

Avec une fonction transparente référentielle, étant donné une entrée et une fonction, vous pourriez la remplacer par une valeur au lieu d'appeler la fonction. Ainsi, au lieu d'appeler plusOne avec un paramètre de 5, nous pourrions simplement le remplacer par 6.

Un autre bon exemple est celui des mathématiques en général. En mathématiques, si l'on donne une fonction et une valeur d'entrée, elle donnera toujours la même valeur de sortie. f(x) = x + 1. Par conséquent, les fonctions en mathématiques sont transparentes sur le plan référentiel.

Ce concept est important pour les chercheurs car il signifie que lorsqu'une fonction est transparente sur le plan référentiel, elle se prête à une parallélisation et à une mise en cache automatiques faciles.

La transparence référentielle est toujours utilisée dans les langages fonctionnels comme Haskell.

--

En revanche, il existe le concept d'opacité référentielle. Cela signifie le contraire. L'appel de la fonction ne produit pas toujours le même résultat.

//global G
int G = 10;

int plusG(int x)
{//G can be modified externally returning different values.
  return x + G;
}

Un autre exemple est une fonction membre dans un langage de programmation orienté objet. Les fonctions membres opèrent généralement sur leurs variables membres et sont donc opaques sur le plan référentiel. Cependant, les fonctions membres peuvent bien sûr être transparentes sur le plan référentiel.

Un autre exemple encore est une fonction qui lit un fichier texte et imprime la sortie. Ce fichier texte externe pourrait changer à tout moment, de sorte que la fonction serait opaque sur le plan référentiel.

Answer 3

Une fonction référentiellement transparente est une fonction qui ne dépend que de son entrée.

Answer 4

(Ceci est un post-scriptum à ma réponse du 25 mars, dans le but de rapprocher la discussion des préoccupations de la programmation fonctionnelle/impérative).

L'idée de transparence référentielle des programmeurs fonctionnels semble différer de la notion standard de trois façons :

• Alors que les philosophes/logiciens utilisent des termes comme "référence", "dénotation", "designatum" et " bedeutung " (le terme allemand de Frege), les programmeurs fonctionnels utilisent le terme " valeur ". (Ce n'est pas entièrement leur fait. Je remarque que Landin, Strachey et leurs descendants ont également utilisé le terme " valeur " pour parler de référence/dénotation. Il se peut qu'il ne s'agisse que d'une simplification terminologique introduite par Landin et Strachey, mais elle semble faire une grande différence lorsqu'elle est utilisée de manière naïve).

• Les programmeurs fonctionnels semblent croire que ces "valeurs" existent au sein du langage de programmation, et non en dehors. Ce faisant, ils diffèrent à la fois des philosophes et des sémanticiens du langage de programmation.

• Ils semblent croire que ces "valeurs" sont censées être obtenues par l'évaluation.

Par exemple, l'article de Wikipedia sur transparence référentielle dit, ce matin :

Une expression est dite transparente sur le plan référentiel si elle peut être remplacée par sa valeur sans changer le comportement d'un programme (en d'autres termes, en produisant un programme qui a les mêmes effets et la même sortie pour la même entrée).

Cela va à l'encontre de ce que disent les philosophes/logiciens. Ils disent qu'un contexte est référentiel ou transparent référentiellement si une expression dans ce contexte peut être remplacée par une autre expression qui fait référence à la même chose (un coréférentiel expression). Qui sont ces philosophes/logiciens ? Il s'agit de Frege , Russell , Whitehead , Carnap , Quine , Église et d'innombrables autres. Chacun d'entre eux est une figure imposante. La puissance intellectuelle combinée de ces logiciens est pour le moins bouleversante. Ils sont tous unanimes pour dire que les référents/dénotations existent en dehors du langage formel et que les expressions au sein du langage ne peuvent parler que à propos de les. Ainsi, tout ce que l'on peut faire dans le langage est de remplacer une expression par une autre expression qui se réfère à la même entité. Les référents/dénotations eux-mêmes ne pas existent au sein de la langue. Pourquoi les programmeurs fonctionnels s'écartent-ils de cette tradition bien établie ?

On peut supposer que les sémanticiens du langage de programmation ont pu les induire en erreur. Mais ce n'est pas le cas.

Landin :

(a) chaque expression a un structure de sous-expression imbriquée, (b) chaque sous-expression dénote quelque chose (généralement un nombre, une valeur de vérité ou un fonction numérique) (c) la chose qu'une expression désigne, c'est-à-dire sa "valeur", ne dépend que des valeurs de ses sous-ensembles. expressions, et non d'autres propriétés de celles-ci. [accentuation ajoutée]

Stoy :

La seule chose qui compte dans une expression est sa valeur, et toute sous-expression peut être remplacée par tout autre élément de valeur égale [souligné par nous]. En outre, la valeur d'une expression est, dans certaines limites, la même chaque fois qu'elle se produit".

Bird et Wadler :

la valeur d'une expression ne dépend que des valeurs de ses constituants (le cas échéant) et ces sous-expressions peuvent être remplacées librement par des autres possédant la même valeur [souligné par nous].

Ainsi, rétrospectivement, les efforts de Landin et Strachey pour simplifier la terminologie en remplaçant "référence"/"dénotation" par "valeur" ont peut-être été malavisés. Dès que l'on entend parler d'une "valeur", on est tenté de penser à un processus d'évaluation qui y conduit. Il est également tentant de penser que ce que l'évaluation produit est la "valeur", même s'il peut être tout à fait clair que ce n'est pas la dénotation. C'est ce que je crois être arrivé au concept de "transparence référentielle" aux yeux des programmeurs fonctionnels. Mais la "valeur" dont parlaient les premiers sémanticiens est la suivante no le résultat d'une évaluation ou la sortie d'une fonction ou autre chose du genre. Il s'agit de la dénotation du terme.

Une fois que nous comprenons la soi-disant "valeur" d'une expression ("référence" ou "dénotation" dans le discours des philosophes classiques) comme un objet mathématique/conceptuel complexe, toutes sortes de possibilités s'ouvrent.

• Strachey a interprété les variables dans les langages de programmation impératifs comme étant Valeurs L Comme je l'ai mentionné dans ma réponse du 25 mars, il s'agit d'un objet conceptuel sophistiqué qui n'a pas de représentation directe dans la syntaxe d'un langage de programmation.
• Il a également interprété les commandes de ces langages comme des fonctions d'état à état, un autre exemple d'objet mathématique complexe qui n'est pas une "valeur" dans la syntaxe.
• Même un appel de fonction à effet secondaire en C a une "valeur" bien définie en tant que transformateur d'état qui fait correspondre les états à des paires d'états et de valeurs (la "monade" dans la terminologie des programmeurs fonctionnels).

La réticence des programmeurs fonctionnels à qualifier ces langages de "transparents sur le plan référentiel" implique simplement qu'ils sont réticents à admettre des objets mathématiques/conceptuels aussi complexes que les "valeurs". D'un autre côté, ils semblent parfaitement disposés à appeler un transformateur d'état une "valeur" lorsqu'il est placé dans leur syntaxe favorite et habillé d'un mot à la mode comme "monade". Je dois dire qu'ils sont totalement incohérents, même si nous leur accordons que leur idée de "transparence référentielle" a une certaine cohérence.

Un peu d'histoire pourrait nous éclairer sur la façon dont ces confusions sont apparues. La période de 1962 à 1967 a été très intense pour Christopher Strachey. Entre 1962 et 1965, il a pris un emploi à temps partiel en tant qu'assistant de recherche avec Maurice Wilkes pour concevoir et implémenter le langage de programmation qui a été connu sous le nom de CPL. Il s'agissait d'un langage de programmation impératif, mais il était censé avoir également de puissantes capacités de langage de programmation fonctionnel. Landin, qui était un employé de Strachey dans sa société de conseil, a eu une énorme influence sur la vision de Strachey des langages de programmation. Dans l'article historique de 1965, " 700 prochains langages de programmation "Landin promeut sans complexe les langages de programmation fonctionnels (les qualifiant de dénotatif ) et décrit les langages de programmation impératifs comme leur "antithèse". Dans la discussion qui s'ensuit, Strachey émet des doutes sur la position ferme de Landin.

... Les DLs forment un sous-ensemble de tous les langages. C'est un sous-ensemble intéressant, mais qui n'est pas pratique à utiliser à moins d'y être habitué. Nous en avons besoin car au moment présent nous ne savons pas comment construire des preuves avec des langages qui incluent des impératifs et des sauts. [accentuation ajoutée]

En 1965, Strachey a pris le poste de Reader à Oxford et semble avoir travaillé essentiellement à plein temps à l'élaboration d'une théorie des impératifs et des sauts. En 1967, il est prêt avec une théorie, qu'il enseigne dans son cours sur " l'impératif ". Concepts fondamentaux des langages de programmation " dans une école d'été à Copenhague. Les notes de cours étaient censées être publiées mais "malheureusement, en raison d'une édition dilatoire l'édition, les actes ne se sont jamais matérialisés ; comme comme une grande partie du travail de Strachey à Oxford, cependant journal a eu une diffusion privée influente". ( Martin Campbell-Kelly )

La difficulté d'obtenir les écrits de Strachey a pu conduire à la propagation des confusions, les gens s'appuyant sur des sources secondaires et des ouï-dire. Mais, maintenant que " Concepts fondamentaux "est facilement disponible sur le web, il n'y a pas besoin de recourir à des suppositions. Nous devrions le lire et nous faire notre propre idée de ce que Strachey voulait dire. En particulier :

• Dans la section 3.2, il traite des "expressions" où il parle de "transparence référentielle de la valeur R".
• Sa section 3.3 traite des "commandes" où il parle de "transparence référentielle de la valeur L".
• Dans la section 3.4.5, il parle de "fonctions et de routines" et déclare que "toute entorse à la transparence référentielle d'une valeur R dans un contexte de valeur R doit soit être éliminé en décomposant l'expression en plusieurs commandes et expressions plus simples. expressions, soit, si cela s'avère difficile, faire l'objet d'un commentaire".

Toute discussion sur la "transparence référentielle" sans comprendre la distinction entre les valeurs L, les valeurs R et les autres objets complexes qui peuplent l'univers conceptuel du programmeur impératif est fondamentalement erronée.

Answer 5

Une expression est transparente sur le plan référentiel si elle peut être remplacée par sa valeur, sans changer l'algorithme, ce qui donne un algorithme qui a les mêmes effets et la même sortie sur la même entrée.