Qu'est-ce que la transparence référentielle?
Qu'est-ce que le terme transparence référentielle signifier? J'ai entendu dire que "cela signifie que vous pouvez remplacer les égaux par des égaux", mais cela semble être une explication insuffisante.
Le terme "transparence référentielle" vient de philosophie analytique , la branche de la philosophie qui analyse les constructions, les déclarations et les arguments en langage naturel basés sur les méthodes de la logique et des mathématiques. En d’autres termes, c’est le sujet le plus proche, en dehors de l’informatique, à ce que nous appelons sémantique du langage de programmation . Le philosophe Willard Quine était responsable de l’initiation du concept de transparence référentielle, mais il était également implicite dans les approches de Bertrand Russell et Alfred Whitehead.
À la base, la "transparence référentielle" est une idée très simple et claire. Le terme "référent" est utilisé dans la philosophie analytique pour parler de la chose à laquelle une expression fait référence . C'est à peu près la même chose que ce que nous entendons par "signification" ou "dénotation" dans la sémantique du langage de programmation. Selon l'exemple d'Andrew Birkett ( article de blog ), le terme "capitale de l'Écosse" désigne la ville d'Édimbourg. C’est un exemple simple de "référent".
Un contexte dans une phrase est "référentiellement transparent" si vous remplacez un terme de ce contexte par un autre terme qui fait référence à la même entité ne modifie pas le sens. . Par exemple
Le Parlement écossais se réunit dans la capitale écossaise.
signifie la même chose que
Le Parlement écossais se réunit à Edimbourg.
Donc, le contexte "Le Parlement écossais se réunit à ..." est un contexte référentiel transparent. Nous pouvons remplacer "la capitale de l'Ecosse" par "Edimbourg" sans en modifier le sens. En d'autres termes, le contexte ne s'intéresse qu'à ce que le terme désigne et à rien d'autre. C’est le sens dans lequel le contexte est "référentiellement transparent".
D'autre part, dans la phrase,
Edimbourg est la capitale de l’Écosse depuis 1999.
nous ne pouvons pas faire un tel remplacement. Si nous le faisions, nous obtiendrions "Édimbourg est Edimbourg depuis 1999", ce qui est stupide à dire, et n’a pas le même sens que la phrase originale. Ainsi, il semblerait que le contexte "Édimbourg a été ... depuis 1999" est opaque de manière référentielle (l'opposé de la transparence référentielle). Apparemment, il se soucie de quelque chose de plus que ce à quoi le terme fait référence. Qu'Est-ce que c'est?
Des choses telles que "la capitale de l'Ecosse" sont appelées des termes définis et elles n'ont pas fait beaucoup de maux de tête aux logiciens et aux philosophes pendant longtemps. Russell et Quine les ont triés en disant qu’ils ne sont pas réellement "référentiels", c’est-à-dire que c’est une erreur de penser que les exemples ci-dessus sont utilisés pour faire référence à des entités. La bonne façon de comprendre "Edimbourg est la capitale de l’Écosse depuis 1999" est de dire
L’Écosse a une capitale depuis 1999 et sa capitale est Edimbourg.
Cette phrase ne peut pas être transformée en une phrase noisette. Problème résolu! Le but de Quine était de dire que le langage naturel est désordonné, ou du moins compliqué, car il est conçu pour être pratique à utiliser, mais les philosophes et les logiciens devraient apporter de la clarté en les comprenant correctement. La transparence référentielle est un outil à utiliser pour apporter une telle clarté de sens .
Qu'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 pour comprendre le langage, c’est-à-dire pour assigner un sens . Christopher Strachey , qui a fondé le domaine de la sémantique des langages de programmation, l’a utilisé dans son étude du sens. Son article fondateur " Concepts fondamentaux dans les langages de programmation " est disponible sur le Web. C'est un beau papier et tout le monde peut le lire et le comprendre. Alors, s'il vous plaît faites-le. Vous serez beaucoup éclairé. Il introduit le terme "transparence référentielle" dans ce paragraphe:
L'une des propriétés les plus utiles des expressions est celle appelée par transparence référentielle Quine. En substance, cela signifie que si nous voulons trouver la valeur d'une expression contenant une sous-expression, la seule chose que nous devons savoir sur la sous-expression est sa valeur. Toute autre caractéristique de la sous-expression, telle que sa structure interne, le nombre et la nature de ses composants, l'ordre dans lequel elles sont évaluées ou la couleur de l'encre dans laquelle elles sont écrites, n'a aucune incidence sur la valeur de l'élément principal. expression.
L'utilisation de "en substance" suggère que Strachey le paraphrase afin de l'expliquer simplement. Les programmeurs fonctionnels semblent comprendre ce paragraphe à leur manière. Il existe 9 autres occurrences de "transparence référentielle" dans le document, mais elles ne semblent pas se soucier des autres. En fait, tout l'article de Strachey est consacré à l'explication de la signification des langages de programmation impératifs . Mais aujourd'hui, les programmeurs fonctionnels affirment que les langages de programmation impératifs ne sont pas référentiellement transparents. Strachey se retournerait dans sa tombe.
Nous pouvons sauver la situation. Nous avons dit que le langage naturel est "compliqué", car il est conçu pour être pratique à utiliser. Les langages de programmation sont les mêmes. Ils sont "en désordre, ou au moins compliqués" car ils sont conçus pour être pratiques à utiliser. Cela ne signifie pas qu'ils doivent nous confondre. Ils doivent juste être compris de la bonne façon, en utilisant un méta langage qui est référentiellement transparent afin que nous ayons une clarté de sens. Dans le document que j'ai cité, Strachey fait exactement cela. Il explique la signification des langages de programmation impératifs en les décomposant en concepts élémentaires, sans jamais perdre la clarté. Une partie importante de son analyse consiste à souligner que les expressions dans les langages de programmation ont deux types de "valeurs", appelées l-values et valeurs-r . Avant le papier de Strachey, cela n'était pas compris et la confusion régnait en maître. Aujourd'hui, la définition de C le mentionne régulièrement et chaque programmeur C comprend la distinction. (Il est difficile de dire si les programmeurs dans les autres langues le comprennent aussi bien.)
Quine et Strachey s'intéressaient tous deux à la signification des constructions de langage qui impliquent une forme de dépendance au contexte. Par exemple, notre exemple "Edimbourg est la capitale de l’Écosse depuis 1999" signifie que "la capitale de l’Écosse" dépend du moment où elle est envisagée. Cette dépendance au contexte est une réalité, tant dans les langages naturels que dans les langages de programmation. Même en programmation fonctionnelle, les variables libres et liées doivent être interprétées en fonction du contexte dans lequel elles apparaissent. La dépendance au contexte de tout type bloque la transparence référentielle, d'une manière ou d'une autre. Si vous essayez de comprendre le sens des termes sans tenir compte des contextes dont ils dépendent, vous vous retrouverez avec une confusion extrême. Quine était préoccupé par le sens de la logique modale. Il a conclu que logique modale était opaque par rapport au référentiel et qu'il convenait de le nettoyer en le traduisant dans un cadre référentiel transparent (par exemple, en considérant la nécessité comme prouvable). Il a largement perdu ce débat. Les logiciens et les philosophes ont trouvé que la sémantique mondiale de Kripke était parfaitement adéquate. Une situation similaire règne également avec une programmation impérative. La dépendance vis-à-vis des états expliquée par Strachey et la dépendance vis-à-vis des magasins expliquées par Reynolds (d'une manière similaire à la sémantique mondiale possible de Kripke) sont parfaitement adéquates. Les programmeurs fonctionnels ne connaissent pas grand chose à cette recherche. Leurs idées sur la transparence référentielle doivent être prises avec un gros grain de sel.
[Note complémentaire: Les exemples ci-dessus illustrent le fait qu'une phrase simple telle que "capitale écossaise" a plusieurs niveaux de signification. À un certain niveau, nous pourrions parler de la capitale à l'heure actuelle. À un autre niveau, nous pourrions parler de toutes les capitales possibles que l’Écosse aurait pu avoir au cours du temps. Nous pouvons "zoomer" sur un contexte particulier et "dézoomer" pour couvrir tous les contextes assez facilement dans la pratique normale. L’efficacité du langage naturel utilise notre capacité à le faire. Les langages de programmation impératifs sont efficaces de la même manière. Nous pouvons utiliser une variable x sur le côté droit d'une affectation (la r-value ) pour parler de sa valeur dans un état particulier. Ou, nous pourrions parler de sa valeur l qui couvre tous les états. Les gens sont rarement déroutés par de telles choses. Cependant, ils peuvent ou non être en mesure d'expliquer avec précision toutes les couches de signification inhérentes aux constructions de langage. Toutes ces couches de signification ne sont pas nécessairement "évidentes" et il est de la science de les étudier correctement. Cependant, l'inarticulation des gens ordinaires pour expliquer de telles significations en couches ne signifie pas qu'elles sont confuses à leur sujet.]
Un "post-scriptum" séparé ci-dessous relie cette discussion aux préoccupations de programmation fonctionnelle et impérative .
La transparence référentielle, terme couramment utilisé en programmation fonctionnelle, signifie que, pour une fonction et une valeur d'entrée, vous recevrez toujours la même sortie. C'est-à-dire qu'aucun état externe n'est utilisé dans la fonction.
Voici un exemple de fonction référentielle transparente:
int plusOne(int x)
{
return x+1;
}
Avec une fonction transparente référentielle, à partir d'une entrée et d'une fonction, vous pouvez 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, à partir d’une fonction et d’une valeur d’entrée, il correspond toujours à la même valeur de sortie. f(x) = x + 1. Par conséquent, les fonctions mathématiques sont transparentes par référence.
Ce concept est important pour les chercheurs car cela signifie que, lorsque vous avez une fonction référentielle transparente, elle se prête facilement à la parallélisation et à la mise en cache automatiques.
La transparence référentielle est toujours utilisée dans des langages fonctionnels tels que Haskell.
-
En revanche, il existe le concept d'opacité référentielle. Cela signifie le contraire. L'appel de la fonction peut ne pas toujours produire la même sortie.
//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 fonctionnent généralement sur ses variables membres et seraient donc opaques par référence. Les fonctions membres peuvent bien entendu être transparentes par référence.
Encore un autre exemple est une fonction qui lit un fichier texte et imprime la sortie. Ce fichier texte externe pouvant changer à tout moment, la fonction serait opaque de manière référentielle.
Une fonction référentiellement transparente est une fonction qui ne dépend que de son entrée.
[Ceci est un post-scriptum de 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 la transparence référentielle par les programmeurs fonctionnels semble différer de la notion standard de trois manières:
Alors que les philosophes/logiciens utilisent des termes tels que "référence", "dénotation", "designatum" et " bedeutung " (terme allemand de Frege), les programmeurs fonctionnels utilisent le terme "valeur". (Ce n’est pas tout à fait leur cas. Je remarque que Landin, Strachey et leurs descendants ont également utilisé le terme "valeur" pour parler de référence/dénotation. C’est peut-être une simplification terminologique introduite par Landin et Strachey, mais cela semble faire grande différence quand utilisé d'une manière naïve.)
Les programmeurs fonctionnels semblent croire que ces "valeurs" existent dans le langage de programmation et non à l'extérieur. Ce faisant, ils diffèrent à la fois des philosophes et des sémantistes du langage de programmation.
Ils semblent croire que ces "valeurs" sont supposées être obtenues par évaluation.
Par exemple, l'article de Wikipedia sur transparence référentielle dit, ce matin:
Une expression est dite référentiellement transparente si elle peut être remplacée par sa valeur sans modifier le comportement d'un programme (en d'autres termes, elle génère un programme ayant les mêmes effets et produisant le même résultat).
Ceci est totalement en contradiction avec ce que disent les philosophes/logiciens. Ils disent qu'un contexte est référentiel ou transparent référentiellement si une expression de ce contexte peut être remplacée par une autre expression qui fait référence à la même chose (a expression coréférentielle ). Qui sont ces philosophes/logiciens? Ils comprennent Frege , Russell , Whitehead , Carnap , Quine , Eglise et d'innombrables autres. Chacun d'entre eux est une figure imposante. Le pouvoir intellectuel combiné de ces logiciens est pour le moins bouleversant. Tous sont unanimes à dire que les référents/dénotations existent en dehors du langage formel et que les expressions dans le langage ne peuvent que parler de eux. Ainsi, tout ce que l’on peut faire dans le langage est de remplacer une expression par une autre expression faisant référence à la même entité. Les référents/dénotations elles-mêmes n'existent pas dans la langue. Pourquoi les programmeurs fonctionnels s'écartent-ils de cette tradition bien établie?
On pourrait présumer que les sémantistes du langage de programmation pourraient les avoir induits en erreur. Mais ils ne l'ont pas fait.
Landin :
(a) chaque expression a une 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 une fonction numérique) , (c ) la chose dénotée par une expression, c’est-à-dire sa "valeur", dépend uniquement des valeurs de ses sous-expressions, et non de leurs autres propriétés. [Ajout de l'emphase]
Stoy :
La seule chose qui compte dans une expression est sa valeur, et toute sous-expression peut être remplacée par toute autre valeur égale [En italique]. De plus, la valeur d'une expression est, dans certaines limites, la même chaque fois qu'elle se produit ".
la valeur d'une expression dépend uniquement des valeurs de ses expressions constitutives (le cas échéant) et ces sous-expressions peuvent être remplacées librement par d'autres personnes possédant la même valeur [Soulignement ajouté].
Ainsi, rétrospectivement, les efforts de Landin et Strachey pour simplifier la terminologie en remplaçant "référence"/"dénotation" par "valeur" auraient peut-être été malavisés. Dès que l'on entend parler d'une "valeur", il est tentant de penser à un processus d'évaluation qui y conduit. Il est également tentant de penser à ce que l’évaluation produit comme la "valeur", même s’il est évident que ce n’est pas la dénotation. Je pense que c’est ce qui est arrivé au concept de "transparence référentielle" aux yeux des programmeurs fonctionnels. Mais la "valeur" dont parlaient les premiers sémantistes est et non le résultat d'une évaluation ou du résultat d'une fonction ou d'une telle chose. C'est la dénotation du terme.
Une fois que nous avons compris la soi-disant "valeur" d'une expression ("référence" ou "dénotation" dans le discours des philosophes classiques) en tant qu'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 des valeurs L , comme indiqué dans ma réponse du 25 mars, qui est un objet conceptuel sophistiqué qui n'a pas de lien direct. représentation dans la syntaxe d'un langage de programmation.
- Il a également interprété des commandes dans des langages tels que des fonctions d'état à état, une autre instance d'un 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 mappe des états à des paires d'états et de valeurs (le "monad" dans la terminologie des programmeurs fonctionnels).
La réticence des programmeurs fonctionnels à appeler ces langages "référentiellement transparents" signifie simplement qu'ils sont réticents à admettre des objets mathématiques/conceptuels complexes en tant que "valeurs". D'autre part, ils semblent parfaitement disposés à appeler un transformateur d'état une "valeur" lorsqu'il l'inscrit dans sa propre syntaxe préférée et qu'il est habillé avec 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 l’origine de ces confusions. La période de 1962 à 1967 a été très intense pour Christopher Strachey. Entre 1962 et 1965, il a occupé un poste d'assistant à la recherche auprès de Maurice Wilkes, à temps partiel, pour concevoir et mettre en œuvre le langage de programmation appelé désormais CPL. C’était un langage de programmation impératif, mais il devait également disposer 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 influence énorme sur la vision de Strachey des langages de programmation. Dans le document phare de 1965 intitulé " Les 700 langages de programmation suivants ", Landin fait la promotion des langages de programmation fonctionnels (en les appelant des langages dénotatifs ) 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 forte de Landin.
... Les listes de distribution forment un sous-ensemble de toutes les langues. Ils constituent un sous-ensemble intéressant, mais qu’il est difficile d’utiliser si vous n’êtes pas habitué. Nous en avons besoin car pour le moment nous ne savons pas construire de preuves avec des langages qui incluent des impératifs et des sauts. [Ajout de l'emphase]
En 1965, Strachey occupa le poste de lecteur à Oxford et semble avoir essentiellement travaillé à plein temps à la formulation d’une théorie des impératifs et des sauts. En 1967, il était prêt avec une théorie qu'il avait enseignée dans son cours sur " Concepts fondamentaux dans les langages de programmation " dans une université d'été à Copenhague. Les notes de cours étaient censées avoir été publiées, mais "malheureusement, à cause de la rédaction dilatoire, les débats ne se sont jamais concrétisés. Cependant, comme beaucoup de travaux de Strachey à Oxford, le document avait une diffusion privée influente." ( Martin Campbell-Kelly )
La difficulté d’obtenir les écrits de Strachey aurait pu conduire à la propagation des confusions, les personnes s’appuyant sur des sources secondaires et des ouï-dire. Mais, maintenant que " Concepts fondamentaux " est facilement disponible sur le Web, il n’est pas nécessaire de recourir à des conjectures. Nous devrions le lire et décider nous-mêmes de ce que Strachey voulait dire. En particulier:
- Dans la section 3.2, il traite des "expressions" lorsqu'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 valeur L".
- Dans la section 3.4.5, il parle de "fonctions et de routines" et déclare que "tout écart de la transparence référentielle de valeur R dans un contexte de valeur R doit être éliminé en décomposant l'expression en plusieurs commandes et expressions plus simples, ou, si cela s'avère difficile, fait 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 d'autres objets complexes qui peuplent l'univers conceptuel du programmeur impératif est fondamentalement erronée.
Une expression est référentiellement transparente si elle peut être remplacée par sa valeur, sans modifier l’algorithme, ce qui donne un algorithme ayant les mêmes effets et une même sortie.
Une fonction référentiellement transparente est une fonction qui agit comme une fonction mathématique; étant donné les mêmes entrées, il produira toujours les mêmes sorties. Cela implique que l'état passé en n'est pas modifié et que la fonction n'a pas d'état en soi.
Si l'étymologie vous intéresse (c.-à-d. Pourquoi ce concept a ce nom particulier), consultez mon blog post sur le sujet. La terminologie vient du philosophe/logicien Quine.
Pour ceux qui ont besoin d'une explication concise, je vais en hasarder une (mais lisez les informations ci-dessous).
La transparence référentielle dans un langage de programmation favorise le raisonnement équationnel - plus vous avez de transparence référentielle, plus il est facile de faire un raisonnement équationnel. Par exemple. avec une (pseudo) définition de fonction,
f x = x + x,
la facilité avec laquelle vous pouvez (en toute sécurité) remplacer f(foo) par foo + foo dans le cadre de cette définition, sans avoir trop de contraintes sur l'endroit où vous pouvez effectuer cette réduction, est une bonne indication de la quantité de référentiel la transparence de votre langage de programmation a.
Par exemple, si foo était x ++ au sens de la programmation en C, vous ne pourriez pas effectuer cette réduction en toute sécurité (c’est-à-dire que si vous exécutiez cette réduction, vous ne retrouveriez pas le même programme que vous avez commencé).
Dans les langages de programmation pratiques, vous ne verrez pas une transparence référentielle parfaite, mais les programmeurs fonctionnels se soucient plus que quiconque (cf. Haskell, où il s’agit d’un objectif fondamental).
(Divulgation complète: je suis un programmeur fonctionnel, vous devez donc prendre cette explication avec un grain de sel.)
- La sémantique dénotationnelle est basée sur la modélisation de langages en construisant des domaines qui constituent denotable values .
- Les programmeurs fonctionnels utilisent le terme value pour décrire la convergence d’un calcul en fonction des règles de réécriture du langage, c’est-à-dire. sa sémantique opérationnelle.
Dans 1, il y a une clarté de deux langues en question:
- celui qui est modélisé, le langage objet
- le langage de la modélisation, le méta langage
En 2, grâce à la proximité de l'objet et des métalangages, ils peuvent être confondus.
En tant que développeur de langage, je constate que je dois constamment me souvenir de cette distinction.
Donc, le professeur Reddy puis-je vous paraphraser ainsi :-)
Dans le contexte de la programmation fonctionnelle et de la sémantique, le terme référentiel Transparence n'est pas référentiellement transparent.
J'espère que la réponse suivante ajoute et qualifie les controversées 1re et 3e réponses
Admettons qu’une expression dénote ou désigne un certain référent. Cependant, la question est de savoir si ces référents peuvent être codés de manière isomorphe dans le cadre d'expressions elles-mêmes, appelant ces expressions «valeurs». Par exemple, les valeurs numériques littérales sont un sous-ensemble de l'ensemble des expressions arithmétiques, les valeurs de vérité sont un sous-ensemble de l'ensemble des expressions booléennes, etc. L'idée est d'évaluer une expression à sa valeur (si elle en a une). Ainsi, le mot "valeur" peut faire référence à une dénotation ou à un élément distingué de l'ensemble des expressions. Mais s’il existe un isomorphisme (une bijection) entre le référent et la valeur, nous pouvons dire qu’ils sont la même chose. (Cela dit, il faut prendre soin de définir Les référents et l'isomorphisme, comme le prouve le domaine de la sémantique dénotationnelle . Pour citer un exemple mentionné dans la réponse à la 3ème réponse, le type de données Algebraic La définition data Nat = Zero | Suc Nat ne correspond pas comme prévu à l'ensemble des nombres naturels.)
Écrivons E[·] pour une expression avec un trou, également connu dans certains milieux comme un "contexte". [·]+1 et [·]++ sont deux exemples de contexte pour les expressions de type C.
Écrivons [[·]] pour la fonction qui prend une expression (sans trou) .__ et délivre son sens (référent, dénotation, etc.) dans un univers fournissant le sens (J'emprunte la notation du champ De la sémantique dénotationnelle.)
Adaptons formellement la définition de Quine comme suit: un contexte E[·]est référentiellement transparent si et seulement si deux expressions quelconques E1 et E2 (sans trous Ici) telles que [[E1]] = [[E2]] (c.-à-d. .same referent), il est alors le cas que [[E[E1]]] = [[E[E2]]] (c’est-à-dire que le trou rempli avec E1 ou E2 donne des expressions qui indiquent également le même referent).
La règle de Leibniz de substitution d'égaux pour égaux est généralement exprimée par 'if E1 = E2 puis E[E1] = E[E2]', qui dit que E[·] est une fonction. Une fonction .__ (ou un programme qui calcule la fonction) est un mappage d’une source À une cible, de sorte qu’il existe au plus un élément cible pour chaque élément source Les fonctions non déterministes sont des noms trompeurs, ce sont des relations, des fonctions Fournissant des ensembles, etc. Si, dans la règle de Leibniz, l'égalité = est Denotational, les doubles crochets sont simplement pris pour acquis et Élidé. Donc, un contexte référentiellement transparent est une fonction. Et la règle de Leibniz est l’ingrédient principal du raisonnement équationnel, aussi le raisonnement équationnel est-il clairement lié à la transparence référentielle.
Bien que [[·]] soit une fonction d'expressions en dénotations, il peut s'agir d'une fonction D'expressions en 'valeurs' comprises comme un sous-ensemble restreint d'expressions Et [[·]] pouvant être compris comme une évaluation.
Maintenant, si E1 est une expression et E2 est une valeur, nous avons ce que je pense que la plupart des gens entendent lors de la définition de la transparence référentielle en termes d’expressions, de valeurs et d’évaluation. Mais comme l’illustrent les 1re et 3e réponses de cette page, il s’agit d’une définition inexacte.
Le problème avec des contextes tels que [·]++ n’est pas un effet secondaire, mais sa valeur n’est pas définie en C de façon isomorphe à sa signification. Les fonctions ne sont pas des valeurs (ainsi, les pointeurs sur les fonctions le sont) alors que ce sont les langages de programmation fonctionnels. Landin, Strachey et les pionniers de la sémantique dénotationnelle ont été assez intelligents pour utiliser les mondes fonctionnels pour donner un sens.
Pour les langages de type C impératifs, nous pouvons (grosso modo) fournir une sémantique aux expressions En utilisant la fonction [[·]] : Expression -> (State -> State x Value).
Value est un sous-ensemble de Expression. State contient des paires (identifiant, valeur). La fonction sémantique prend une expression et fournit en tant que Sa signification, une fonction de l'état actuel au couple avec l'état Mis à jour et une valeur. Par exemple, [[x]] est la fonction de l'état actuelà la paire dont le premier composant est l'état actuel et dont le second composant Est la valeur de x. Au contraire, [[x++]] est la fonction de l'état actuel À la paire dont le premier composant est un état dans lequel la valeur De x est incrémentée et dont le second composant est cette valeur même. En ce sens, le contexte [·]++ est référentiel transparent si et seulement s'il répond à la définition de Donnée ci-dessus.
Je pense que les programmeurs fonctionnels sont autorisés à utiliser la transparence référentielle en Dans le sens où ils récupèrent naturellement [[·]] en fonction d’expressions en valeurs . __.dénotation. La monade d'état est (en partie) un mécanisme propre pour passer (ou enfiler) l'état.
Notez que ce concept de "signification" est quelque chose qui se passe dans l'esprit de l'observateur. Ainsi, la même "référence" peut signifier différentes choses pour différentes personnes. Ainsi, par exemple, nous avons une page sur l'homonymie à Edimbourg dans Wikipedia.
Un problème connexe qui peut apparaître dans le contexte de la programmation pourrait être le polymorphisme.
Et peut-être devrions-nous avoir un nom pour le cas particulier du polymorphisme (ou peut-être même de la coulée) où, pour nos besoins, les différents cas polymorphes sont sémantiquement équivalents (au lieu d'être simplement similaires. Par exemple, le nombre 1 - qui pourrait être représenté en utilisant un type entier, ou un type complexe ou toute une variété d'autres types - peut être traité de manière polymorphe).
J'ai trouvé la définition de transparence référentielle dans le livre "Structure et implémentation de programmes d'ordinateur" (le livre Wizard) utile car elle est complétée par une explication de la manière dont transparence référentielle est violé en introduisant l'opération assignation. Regardez la diapositive suivante que j'ai faite sur le sujet: https://www.slideshare.net/pjschwarz/introducing-assignment-invalidates-the-substitution-model-of-evaluation-and-violates-referential-transparency- comme expliqué dans sicp-the-wizard-book
La transparence référentielle peut être simplement énoncée comme suit:
- Une expression évaluant toujours le même résultat dans n'importe quel contexte [1] ,
- Une fonction, si on lui donne deux fois les mêmes paramètres, doit produire le même résultat deux fois [2] .
Par exemple, le langage de programmation Haskell est un langage purement fonctionnel; ce qui signifie qu'il est référentiellement transparent.