Cette définition est supérieure à celle que j'ai fournie dans ma réponse précédente, car elle est succincte et elle est plus générale. Mais il peut être plus difficile à comprendre, car les implications des théorèmes d'incomplétude applicables à la programmation et à la vie en général sont difficiles à comprendre pour les humains.
L'explication citée de la définition discute du rôle que joue la programmation fonctionnelle pure dans la programmation déclarative.
Déclaratif vs impératif
La propriété déclarative est étrange, obtuse et difficile à saisir dans une définition techniquement précise qui reste générale et non ambiguë, car c'est une notion naïve que nous pouvons déclarer le sens (alias sémantique) du programme sans encourir d'effets secondaires involontaires. Il existe une tension inhérente entre l'expression du sens et l'évitement des effets involontaires, et cette tension dérive en fait des théorèmes d'incomplétude de la programmation et de notre univers.
Il est simpliste, techniquement imprécis et souvent ambigu de définir déclaratif comme « quoi faire » et impératif comme « comment faire » . Un cas ambigu est le « quoi » est le « comment » dans un programme qui produit un programme - un compilateur.
Évidemment, la récursion illimitée qui rend un langage de Turing complet , est également analogue dans la sémantique - pas seulement dans la structure syntaxique de l'évaluation (alias la sémantique opérationnelle). Il s'agit logiquement d'un exemple analogue au théorème de Gödel: « tout système complet d'axiomes est également incohérent ». Méditez sur l'étrangeté contradictoire de cette citation! C'est aussi un exemple qui montre comment l'expression de la sémantique n'a pas de limite prouvable, donc nous ne pouvons pas prouver 2 qu'un programme (et de façon analogue sa sémantique) stoppe alias le théorème de Halting.
Les théorèmes d'incomplétude dérivent de la nature fondamentale de notre univers qui, comme indiqué dans la deuxième loi de la thermodynamique, est « l'entropie (alias le # de possibilités indépendantes) tend à atteindre son maximum pour toujours ». Le codage et la conception d'un programme ne sont jamais terminés - il est vivant! - car il tente de répondre à un besoin du monde réel, et la sémantique du monde réel est en constante évolution et tend vers plus de possibilités. Les humains ne cessent de découvrir de nouvelles choses (y compris des erreurs dans les programmes ;-).
Pour capturer précisément et techniquement cette notion souhaitée susmentionnée au sein de cet univers étrange qui n'a pas de bord (réfléchissez à cela! Il n'y a pas «à l'extérieur» de notre univers), nécessite une définition laconique mais trompeusement pas simple qui sonnera incorrecte jusqu'à ce qu'elle soit expliquée profondément.
Définition:
La propriété déclarative est l'endroit où il ne peut exister qu'un seul ensemble d'instructions possible pouvant exprimer chaque sémantique modulaire spécifique.
La propriété impérative 3 est le duel, où la sémantique est incohérente dans la composition et / ou peut être exprimée avec des variations d'ensembles d'énoncés.
Cette définition du déclaratif est distinctement locale dans la portée sémantique, ce qui signifie qu'elle nécessite qu'une sémantique modulaire conserve sa signification cohérente, peu importe où et comment elle est instanciée et utilisée dans la portée globale . Ainsi, chaque sémantique modulaire déclarative doit être intrinsèquement orthogonale à toutes les autres possibles - et non un algorithme ou un modèle global impossible (en raison des théorèmes d'incomplétude) pour témoigner de la cohérence, ce qui est également le point de " Plus n'est pas toujours mieux » de Robert Harper, professeur d'informatique à l'Université Carnegie Mellon, l'un des concepteurs de Standard ML.
Des exemples de ces sémantiques déclaratives modulaires incluent les foncteurs de théorie des catégories, par exemple leApplicative typage nominal, les espaces de noms, les champs nommés et les écritures au niveau opérationnel de la sémantique, puis la programmation fonctionnelle pure.
Ainsi, des langages déclaratifs bien conçus peuvent exprimer plus clairement le sens , quoique avec une certaine perte de généralité dans ce qui peut être exprimé, mais un gain dans ce qui peut être exprimé avec une cohérence intrinsèque.
Un exemple de la définition susmentionnée est l'ensemble des formules dans les cellules d'un tableur - qui ne devraient pas donner la même signification lorsqu'elles sont déplacées vers différentes cellules de colonne et de ligne, c'est-à-dire que les identificateurs de cellule ont été modifiés. Les identifiants de cellule font partie de la signification voulue et n'en sont pas superflus. Ainsi, chaque résultat de feuille de calcul est unique par rapport aux identificateurs de cellule dans un ensemble de formules. La sémantique modulaire cohérente dans ce cas est l'utilisation d'identificateurs de cellules comme entrée et sortie de fonctions pures pour les formules de cellules (voir ci-dessous).
Hyper Text Markup Language aka HTML - le langage des pages Web statiques - est un exemple de langage hautement (mais pas parfaitement 3 ) déclaratif qui (au moins avant HTML 5) n'avait pas la capacité d'exprimer un comportement dynamique. Le HTML est peut-être la langue la plus facile à apprendre. Pour un comportement dynamique, un langage de script impératif tel que JavaScript était généralement combiné avec HTML. Le HTML sans JavaScript correspond à la définition déclarative car chaque type nominal (c'est-à-dire les balises) conserve sa signification cohérente sous composition dans les règles de la syntaxe.
Une définition concurrente du déclaratif est les propriétés commutatives et idempotentes des instructions sémantiques, c'est-à-dire que les instructions peuvent être réorganisées et dupliquées sans changer la signification. Par exemple, les instructions affectant des valeurs aux champs nommés peuvent être réorganisées et dupliquées sans changer la signification du programme, si ces noms sont modulaires par rapport à un ordre implicite. Les noms impliquent parfois un ordre, par exemple les identifiants de cellule incluent leur position de colonne et de ligne - déplacer un total sur une feuille de calcul change sa signification. Sinon, ces propriétés nécessitent implicitement une valeur globalecohérence de la sémantique. Il est généralement impossible de concevoir la sémantique des instructions afin qu'elles restent cohérentes si elles sont ordonnées ou dupliquées de manière aléatoire, car l'ordre et la duplication sont intrinsèques à la sémantique. Par exemple, les énoncés «Foo existe» (ou construction) et «Foo n'existe pas» (et destruction). Si l'on considère l'incohérence aléatoire endémique de la sémantique voulue, alors on accepte cette définition comme suffisamment générale pour la propriété déclarative. En substance, cette définition est vide en tant que définition généralisée car elle tente de rendre la cohérence orthogonale à la sémantique, c'est-à-dire de défier le fait que l'univers de la sémantique est dynamiquement illimité et ne peut pas être capturé dans un paradigme de cohérence globale .
Le fait d'exiger les propriétés commutatives et idempotentes pour (l'ordre d'évaluation structurelle de) la sémantique opérationnelle de niveau inférieur convertit la sémantique opérationnelle en une sémantique modulaire localisée déclarative , par exemple la programmation fonctionnelle pure (y compris la récursion au lieu des boucles impératives). Ensuite, l'ordre opérationnel des détails d'implémentation n'affecte pas (c'est-à-dire se propage globalement ) la cohérence de la sémantique de niveau supérieur. Par exemple, l'ordre d'évaluation (et théoriquement aussi la duplication des) formules de feuille de calcul n'a pas d'importance car les sorties ne sont copiées dans les entrées qu'après que toutes les sorties ont été calculées, c'est-à-dire de manière analogue aux fonctions pures.
C, Java, C ++, C #, PHP et JavaScript ne sont pas particulièrement déclaratifs. La syntaxe de Copute et la syntaxe de Python sont couplées de manière plus déclarative aux résultats escomptés , c'est-à-dire à une sémantique syntaxique cohérente qui élimine les étrangers afin que l'on puisse facilement comprendre le code après l'avoir oublié. Copute et Haskell imposent le déterminisme de la sémantique opérationnelle et encouragent « ne vous répétez pas » (SEC), car ils ne permettent que le pur paradigme fonctionnel.
2 Même lorsque nous pouvons prouver la sémantique d'un programme, par exemple avec le langage Coq, cela est limité à la sémantique qui est exprimée dans le typage , et le typage ne peut jamais capturer toute la sémantique d'un programme - pas même pour les langages qui sont pas Turing complet, par exemple avec HTML + CSS, il est possible d'exprimer des combinaisons incohérentes qui ont donc une sémantique non définie.
3 De nombreuses explications prétendent à tort que seule la programmation impérative a des instructions ordonnées syntaxiquement. J'ai clarifié cette confusion entre programmation impérative et programmation fonctionnelle . Par exemple, l'ordre des instructions HTML ne réduit pas la cohérence de leur signification.
en programmation fonctionnelle ... la plage de variation d'une variable est un type
Selon la façon dont on distingue la programmation fonctionnelle de la programmation impérative, votre «assignable» dans un programme impératif peut également avoir un type qui limite la variabilité.
La seule définition non confuse que j'apprécie actuellement pour la programmation fonctionnelle est a) les fonctions en tant qu'objets et types de première classe, b) la préférence pour la récursivité sur les boucles, et / ou c) les fonctions pures - c'est-à-dire les fonctions qui n'ont pas d'impact sur la sémantique souhaitée du programme lorsqu'il est mémorisé ( donc la programmation fonctionnelle parfaitement pure n'existe pas dans une sémantique dénotationnelle à usage général en raison des impacts de la sémantique opérationnelle, par exemple l'allocation de mémoire ).
La propriété idempotente d'une fonction pure signifie que l'appel de fonction sur ses variables peut être substitué par sa valeur, ce qui n'est généralement pas le cas pour les arguments d'une procédure impérative. Les fonctions pures semblent être déclaratives par rapport aux transitions d'état non composées entre les types d'entrée et de résultat.
Mais la composition des fonctions pures ne maintient pas une telle cohérence, car il est possible de modéliser un processus impératif d'effets secondaires (état global) dans un langage de programmation fonctionnel pur, par exemple IOMonad de Haskell et de plus il est tout à fait impossible d'empêcher de le faire dans tout langage de programmation purement fonctionnel Turing complet.
Comme je l'ai écrit en 2012, ce qui semble être le même consensus de commentaires dans votre récent blog , que la programmation déclarative est une tentative de capturer l'idée que la sémantique prévue n'est jamais opaque. Des exemples de sémantique opaque sont la dépendance à l'ordre, la dépendance à l'effacement de la sémantique de niveau supérieur au niveau de la couche sémantique opérationnelle (par exemple, les transtypages ne sont pas des conversions et les génériques réifiés limitent la sémantique de niveau supérieur ), et la dépendance à des valeurs variables qui ne peuvent pas être vérifiées (prouvées correct) par le langage de programmation.
J'ai donc conclu que seules les langues complètes non-Turing peuvent être déclaratives.
Ainsi, un attribut non ambigu et distinct d'un langage déclaratif pourrait être qu'il peut être prouvé que sa sortie obéit à un ensemble énumérable de règles génératives. Par exemple, pour tout programme HTML spécifique (en ignorant les différences de divergence entre les interprètes) qui n'est pas scripté (c'est-à-dire n'est pas Turing complet), sa variabilité de sortie peut être énumérable. Ou plus succinctement, un programme HTML est une fonction pure de sa variabilité. Idem un tableur est une fonction pure de ses variables d'entrée.
Il me semble donc que les langages déclaratifs sont l'antithèse de la
récursion illimitée , c'est-à-dire que, selon le deuxième théorème d'incomplétude de Gödel, les théorèmes autoréférentiels ne peuvent pas être prouvés.
Lesie Lamport a écrit un conte de fées sur la façon dont Euclide aurait pu contourner les théorèmes d'incomplétude de Gödel appliqués aux preuves mathématiques dans le contexte du langage de programmation par la congruence entre les types et la logique (correspondance Curry-Howard, etc.).