Qu'est-ce que la programmation déclarative?
J'entends souvent ce terme balayer dans différents contextes. Qu'Est-ce que c'est?
La programmation déclarative consiste à écrire votre code de manière à décrire ce que vous voulez faire et non pas la façon dont vous voulez le faire. Il appartient au compilateur de déterminer le comment.
SQL et Prolog sont des exemples de langages de programmation déclaratifs.
Les autres réponses font déjà un travail fantastique en expliquant ce qu'est la programmation déclarative. Je vais donc simplement donner quelques exemples de pourquoi cela pourrait être utile.
Indépendance du contexte
Les programmes déclaratifs sont indépendants du contexte . Parce qu'ils déclarent seulement quel est l'objectif ultime, mais pas les étapes intermédiaires pour atteindre cet objectif, le même programme peut être utilisé dans différents contextes. Cela est difficile à faire avec programmes impératifs , car ils dépendent souvent du contexte (par exemple, l’état caché).
Prenons yacc comme exemple. C'est un générateur d'analyseur syntaxique aka. compiler compiler, un DSL déclaratif externe permettant de décrire la grammaire d'un langage, de sorte qu'un analyseur syntaxique de ce langage puisse être généré automatiquement à partir de la description. En raison de son indépendance du contexte, vous pouvez faire beaucoup de choses différentes avec une telle grammaire:
- Générer un analyseur C pour cette grammaire (cas d'utilisation original pour
yacc) - Générer un analyseur C++ pour cette grammaire
- Générer un analyseur Java pour cette grammaire (à l'aide de Jay)
- Générer un analyseur C # pour cette grammaire (à l'aide de GPPG)
- Générer un analyseur Ruby pour cette grammaire (à l'aide de Racc)
- Générer une visualisation d'arborescence pour cette grammaire (à l'aide de GraphViz)
- il vous suffit simplement de mettre en évidence le fichier source yacc lui-même et de l'inclure dans votre Manuel de référence en tant que spécification syntaxique de votre langue.
Et beaucoup plus …
Optimisation
Comme vous ne spécifiez pas à l'ordinateur les étapes à suivre et dans quel ordre, il peut réorganiser votre programme beaucoup plus librement, voire même exécuter certaines tâches en parallèle. Un bon exemple est un planificateur de requêtes et un optimiseur de requêtes pour une base de données SQL. La plupart des bases de données SQL vous permettent d'afficher la requête qu'elles sont en train de s'exécuter par rapport à la requête que vous avez demandée les exécuter. Souvent, ces requêtes ne ressemblent à rien . Le planificateur de requêtes tient compte de choses que vous n'auriez même pas imaginées: la latence rotationnelle du disque Platter, par exemple, ou le fait qu'une application complètement différente pour un utilisateur complètement différent vient d'exécuter une requête similaire et la table que vous êtes. rejoindre avec et que vous avez travaillé si dur pour éviter le chargement est déjà en mémoire de toute façon.
Il existe un compromis intéressant ici: la machine doit travailler plus dur pour comprendre comment faire quelque chose que dans un langage impératif, mais quand il le calcule, il dispose de beaucoup plus de liberté et d'informations pour la phase d'optimisation.
Librement:
La programmation déclarative tend vers: -
- Ensembles de déclarations, ou déclarations déclaratives, chacune ayant une signification (souvent dans le domaine du problème) et pouvant être comprise indépendamment et isolément.
La programmation impérative tend vers: -
- Des séquences de commandes, chacune effectuant une action; mais qui peut ou non avoir une signification dans le domaine du problème.
En conséquence, un style impératif aide le lecteur à comprendre les mécanismes de ce que le système est en train de faire, mais peut ne donner que peu d'informations sur le problème qu'il est censé résoudre. D'autre part, un style déclaratif aide le lecteur à comprendre le domaine du problème et l'approche que le système adopte pour résoudre le problème, mais est moins informatif en matière de mécanique.
Les programmes réels (même ceux écrits dans des langues qui favorisent les extrémités du spectre, telles que ProLog ou C) tendent à présenter les deux styles à des degrés divers, à différents moments, afin de satisfaire les diverses complexités et besoins de communication de la pièce. Un style n'est pas supérieur à l'autre; ils servent simplement à des fins différentes et, comme dans beaucoup d'autres choses de la vie, la modération est la clé.
Voici un exemple.
En CSS (utilisé pour styliser les pages HTML), si vous voulez qu'un élément d'image mesure 100 pixels de haut et 100 pixels de large, vous devez simplement "déclarer" que c'est ce que vous voulez, comme suit:
#myImageId {
height: 100px;
width: 100px;
}
Vous pouvez considérer CSS comme un langage déclaratif de "feuille de style".
Le moteur de navigateur qui lit et interprète cette CSS est libre de rendre l’image aussi haute et aussi large qu’elle le souhaite. Différents moteurs de navigateur (par exemple, le moteur pour IE, le moteur pour Chrome) implémenteront cette tâche différemment.
Bien entendu, leurs implémentations uniques ne sont PAS écrites dans un langage déclaratif, mais dans un langage procédural tel que Assembly, C, C++, Java, JavaScript ou Python. Ce code est un tas d'étapes à exécuter étape par étape (et peut inclure des appels de fonction). Cela peut faire des choses comme interpoler des valeurs de pixels et afficher à l'écran.
Je suis désolé, mais je dois être en désaccord avec beaucoup d'autres réponses. Je voudrais mettre fin à ce malentendu confus quant à la définition de la programmation déclarative.
Définition
La transparence référentielle (RT) des sous-expressions est l'attribut seulement requis d'une expression de programmation déclarative , car c'est le seul attribut qui ne soit pas partagé avec la programmation impérative .
Les autres attributs cités de la programmation déclarative proviennent de cette RT. S'il vous plaît cliquez sur le lien ci-dessus pour l'explication détaillée.
Exemple de feuille de calcul
Deux réponses ont mentionné la programmation par tableur. Dans les cas où la programmation de tableur (formules a.k.a.) n'accède pas à l'état mutable global, il s'agit alors d'une programmation déclarative. Cela est dû au fait que les valeurs des cellules mutables sont les valeurs monolithiques entrée et sortie de la main() (le programme complet). Les nouvelles valeurs ne sont pas écrites dans les cellules après l'exécution de chaque formule. Par conséquent, elles ne sont pas modifiables pour la durée du programme déclaratif (exécution de toutes les formules du tableur). Ainsi, les formules considèrent donc les cellules mutables comme immuables les unes par rapport aux autres. Une fonction RT est autorisée à accéder à immuable état global (et aussi mutable local état ).
Ainsi, la possibilité de muter les valeurs dans les cellules lorsque le programme se termine (en tant que sortie de main()), ne les rend pas modifiables en tant que valeurs stockées dans le contexte des règles. La distinction clé est que les valeurs des cellules ne sont pas mises à jour après l'exécution de chaque formule de la feuille de calcul. Par conséquent, l'ordre d'exécution des formules n'a pas d'importance. Les valeurs de cellule sont mises à jour après l'exécution de toutes les formules déclaratives.
La programmation déclarative est l’image, la programmation impérative étant des instructions pour peindre cette image.
Vous écrivez dans un style déclaratif si vous "dites ce que c'est", plutôt que de décrire les étapes que doit suivre l'ordinateur pour arriver où vous le souhaitez.
Lorsque vous utilisez XML pour baliser des données, vous utilisez une programmation déclarative parce que vous dites "Ceci est une personne, c'est un anniversaire, et il y a une adresse postale".
Quelques exemples de cas où la programmation déclarative et impérative sont combinées pour un plus grand effet:
Windows Presentation Foundation utilise la syntaxe XML déclarative pour décrire l'apparence d'une interface utilisateur et les relations (liaisons) entre les contrôles et les structures de données sous-jacentes.
Les fichiers de configuration structurés utilisent une syntaxe déclarative (aussi simple que des paires "clé = valeur") pour identifier la signification d'une chaîne ou d'une valeur de données.
Le HTML marque le texte avec des balises qui décrivent le rôle que chaque morceau de texte a par rapport au document entier.
Depuis que j'ai écrit ma réponse précédente, j'ai formulé un nouvelle définition de la propriété déclarative qui est cité ci-dessous. J'ai également défini la programmation impérative comme étant la propriété double.
Cette définition est supérieure à celle que j’avais fournie dans ma réponse précédente, car elle est succincte et plus générale. Mais il peut être plus difficile de parler, 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 traite du rôle joué par 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 il est naïf de pouvoir déclarer le sens (une sémantique) du programme sans provoquer d’effets secondaires non voulus. Il existe une tension inhérente entre l'expression du sens et la prévention des effets non intentionnels, et cette tension découle en réalité du théorèmes d'inachèvement de la programmation et de notre univers.
Il est trop simpliste, techniquement imprécis et souvent ambigu de définir le déclaratif comme “ que 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.
Evidemment, le récursion sans limite qui rend un langage complet de Turing , est également analogue dans la sémantique - pas seulement dans la structure syntaxique de l'évaluation (a.k.a. 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 aussi incohérent". Pensez à l'étrangeté contradictoire de cette citation! C'est aussi un exemple qui montre que l'expression de la sémantique n'a pas de lien prouvable. Nous ne pouvons donc pas prouver 2 qu'un programme (et de manière analogue sa sémantique) stoppe a.k.a. le théorème de Halting.
Les théorèmes d'inachèvement découlent de la nature fondamentale de notre univers, qui, comme l'indique la deuxième loi de la thermodynamique, est " l'entropie (alias le nombre de possibilités indépendantes) tend vers le 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 réel, et la sémantique du monde réel change constamment et tend à plus de possibilités. Les humains ne cessent jamais de découvrir de nouvelles choses (y compris des erreurs dans les programmes ;-).
Pour capturer précisément et techniquement cette notion désirée dans cet univers étrange qui n'a pas de limite (réfléchissez qu'il n'y a pas de "dehors" de notre univers), nécessite une définition concise mais trompeuse-pas-simple qui semblera incorrecte jusqu'à ce qu'elle soit expliquée profondément.
Définition:
La propriété déclarative est celle où il ne peut exister qu'un seul ensemble d'instructions pouvant exprimer chaque sémantique modulaire spécifique.
La propriété impérative est le double, où la sémantique est incohérente dans la composition et/ou peut être exprimée avec des variations de jeux d'énoncés.
Cette définition du déclaratif est distinctement local en portée sémantique, ce qui signifie qu’une sémantique modulaire doit conserver son sens cohérent quels que soient le lieu et la manière dont elle est instanciée et utilisée global = portée. Ainsi, chaque sémantique modulaire déclarative devrait être intrinsèquement orthogonale à tous les autres possibles - et non impossible (en raison de théorèmes d'incomplétude) global algorithme ou modèle de vérification de la cohérence, qui constitue également le point de "- Plus n'est pas toujours préférable ”par 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 la théorie des catégories, par ex. le
Applicative, typage nominal, espaces de noms, champs nommés et w.r.t. au niveau opérationnel de la sémantique puis de la programmation fonctionnelle pure.Ainsi, des langages déclaratifs bien conçus peuvent exprimer plus clairement le sens , avec toutefois 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 de formules dans les cellules d'un programme de feuille de calcul - qui ne devraient pas donner la même signification lorsqu'elles sont déplacées vers des cellules de colonne et de ligne différentes, c'est-à-dire que les identificateurs de cellule ont été modifiés. Les identificateurs de cellule font partie de la signification voulue et ne sont pas superflus. Donc, chaque résultat de feuille de calcul est unique w.r.t. 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 des fonctions pure pour les formules de cellules (voir ci-dessous).
Hyper Text Markup Language ou HTML - le langage pour les pages Web statiques - est un exemple de langage hautement (mais pas parfaitement --- ) déclaratif qui (du moins avant HTML 5) n'avait pas la capacité d'exprimer un comportement dynamique . 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 associé à 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.
Les définitions commutative et idempotente des instructions sémantiques sont une définition concurrente, c’est-à-dire que les instructions peuvent être réorganisées et dupliquées sans en changer le sens. Par exemple, les instructions attribuant des valeurs à des champs nommés peuvent être réorganisées et dupliquées sans modifier la signification du programme, si ces noms sont modulaires w.r.t. à tout ordre implicite. Les noms impliquent parfois un ordre, par exemple Les identifiants de cellule incluent leur position dans la colonne et la ligne. Le déplacement d'un total sur une feuille de calcul change sa signification. Sinon, ces propriétés exigent implicitement global la cohé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 qu’une incohérence aléatoire est une endémique de la sémantique prévue, on accepte alors cette définition comme assez 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 global = paradigme de cohérence.
Exiger les propriétés commutatives et idempotentes de la sémantique opérationnelle de niveau inférieur (ordre d’évaluation structurelle) convertit la sémantique opérationnelle en une sémantique déclarative localisée, par ex. programmation fonctionnelle pure (y compris la récursion au lieu de boucles impératives). Ensuite, l'ordre opérationnel des détails d'implémentation n'a pas d'impact (c'est-à-dire, étalé globalement dans) la cohérence de la sémantique de niveau supérieur. Par exemple, l'ordre d'évaluation des formules de la feuille de calcul (et, théoriquement, la duplication de ces dernières) importent peu, car les sorties ne sont copiées dans les entrées qu'après le calcul de toutes les sorties, c'est-à-dire analogues à des 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 de manière plus déclarative couplé aux résultats attendus , c'est-à-dire une sémantique syntaxique cohérente qui élimine les éléments superflus afin de pouvoir facilement comprendre le code après l'avoir oublié. Copute et Haskell appliquent un déterminisme de la sémantique opérationnelle et encouragent “ ne vous répétez pas ” (DRY), car ils ne permettent que le paradigme fonctionnel pur.
2 Même lorsque nous pouvons prouver la sémantique d'un programme, par ex. avec le langage Coq, cela est limité à la sémantique qui est exprimée en le typage , et le typage ne peut jamais capturer toute la sémantique d'un programme - pas même pour les langages qui ne sont pas complets de Turing, par ex. avec HTML + CSS, il est possible d'exprimer des combinaisons incohérentes qui ont donc une sémantique non définie.
De nombreuses explications prétendent à tort que seule la programmation impérative contient des instructions ordonnées syntaxiquement. J'ai clarifié ceci confusion entre la programmation impérative et fonctionnelle . Par exemple, l'ordre des instructions HTML ne réduit pas la cohérence de leur signification.
Edit: J'ai posté le commentaire suivant sur le blog de Robert Harper:
en programmation fonctionnelle ... la plage de variation d'une variable est un type
Selon la manière dont on distingue la programmation fonctionnelle d’impératif, votre type de "assignable" dans un programme impératif peut également avoir un type plaçant une limite à sa variabilité.
La seule définition non confuse que j'apprécie actuellement pour la programmation fonctionnelle est a) fonctionne comme objets et types de première classe, b) préférence pour la récursion par rapport aux boucles et/ou c) 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émoisé (ainsi, 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. allocation de mémoire).
La propriété idempotent d'une fonction pure signifie que l'appel de fonction sur ses variables peut être remplacé 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. aux transitions d'état non composées entre les types d'entrée et de résultat.
Mais la composition de fonctions pures ne conserve pas cette cohérence, car il est possible de modéliser un processus impératif d’effets secondaires (état global) dans un langage de programmation purement fonctionnel, par ex. IOMonad de Haskell et, en outre, il est tout à fait impossible d'empêcher de le faire dans n'importe quel langage de programmation purement fonctionnel complet de Turing.
Comme j’ai écrit en 2012, ce qui semble ressembler au même consensus en ce qui concerne votre blog récent , cette programmation déclarative est une tentative de saisir l’idée que la sémantique voulue n’est jamais opaque. Les exemples de sémantique opaque sont la dépendance vis-à-vis de l'ordre, la suppression de la sémantique de niveau supérieur au niveau de la couche sémantique opérationnelle (par exemple, les conversions 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 peut pas être vérifié (prouvé 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 distinct et non ambigu d’un langage déclaratif pourrait être que son résultat 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 dans la manière dont les interprètes divergent) qui n’est pas scripté (c’est-à-dire n’est pas complet), sa variabilité en sortie peut être énumérable. Ou plus succinctement, un programme HTML est une pure fonction de sa variabilité. Idem, un tableur est une pure fonction de ses variables d'entrée.
Il me semble donc que les langages déclaratifs sont l’antithèse de récursion sans bornes , c’est-à-dire que le second théorème d’incomplétude de Gödel ne permet pas de prouver les théorèmes autoréférentiels.
Lesie Lamport écrit Un conte de fées sur la manière dont Euclid aurait pu travailler sur les théorèmes d'inachèvement de Gödel appliqués aux preuves mathématiques dans le contexte du langage de programmation afin de faire correspondre les types et la logique (correspondance de Curry-Howard, etc.).
imaginez une page Excel. Avec des colonnes remplies de formules pour calculer votre déclaration de revenus.
Toute la logique est déclarée dans les cellules, l'ordre du calcul est déterminé par la formule elle-même plutôt que par la procédure.
C'est un peu ce qu'est la programmation déclarative. Vous déclarez l'espace du problème et la solution plutôt que le flux du programme.
Prolog est le seul langage déclaratif que j'ai utilisé. Cela nécessite un type de réflexion différent, mais il est bon d'apprendre si vous vous exposez simplement à autre chose que le langage de programmation procédural typique.
J'ai affiné ma compréhension de la programmation déclarative, depuis décembre 2011, année où j'ai fourni ne réponse à cette question. Voici ma compréhension actuelle.
La version longue de ma compréhension (recherche) est détaillée à ce lien, que vous devriez lire pour acquérir une compréhension profonde de le résumé que je fournirai ci-dessous.
La programmation impérative est où l’état mutable est stocké et lu, ainsi l’ordre et/ou la duplication des instructions de programme peut modifier le comportement (la sémantique) du programme (et même causer un bogue, un comportement involontaire).
Au sens le plus naïf et extrême (comme je l’ai affirmé dans ma réponse précédente), la programmation déclarative (DP) évite tous les états mutables mémorisés; ainsi, la commande et/ou la duplication des instructions de programme peut [ ~ # ~] pas [~ # ~] modifie le comportement (la sémantique) du programme.
Cependant, une définition aussi extrême ne serait pas très utile dans le monde réel, car presque tous les programmes impliquent un état mutable stocké. Le exemple de feuille de calcul est conforme à cette définition extrême de DP, car le code de programme complet est exécuté jusqu'à achèvement avec une copie statique de l'état d'entrée, avant que les nouveaux états ne soient stockés. Ensuite, si un état est modifié, cela est répété. Mais la plupart des programmes du monde réel ne peuvent pas se limiter à un modèle monolithique de changement d'état.
Une définition plus utile de DP est que l'ordre et/ou la duplication d'instructions de programmation ne modifie aucune sémantique opaque. En d'autres termes, il n'y a pas de changement aléatoire caché dans la sémantique - tout changement dans l'ordre des instructions du programme et/ou la duplication ne provoque que des changements intentionnels et transparents dans le comportement du programme.
La prochaine étape consisterait à discuter des modèles de programmation ou des paradigmes qui aident le PDD, mais ce n’est pas la question.
C'est une méthode de programmation basée sur la description de ce que doit faire ou être quelque chose à la place de la description comment ça devrait marcher.
En d'autres termes, vous n'écrivez pas des algorithmes constitués d'expressions, vous vous contentez de définir comment vous voulez que les choses se passent. HTML et WPF sont deux bons exemples.
Cet article de Wikipédia est un bon aperçu: http://en.wikipedia.org/wiki/Declarative_programming
Décrire sur un ordinateur ce que vous voulez, pas comment faire quelque chose.
La programmation déclarative consiste à programmer avec des déclarations, c'est-à-dire des phrases déclaratives. Les phrases déclaratives ont un certain nombre de propriétés qui les distinguent des phrases impératives. Les déclarations sont notamment:
- commutatif (peut être réorganisé)
- associatif (peut être regroupé)
- idempotent (peut répéter sans changement de sens)
- monotone (les déclarations ne soustraient pas les informations)
Un point pertinent est que ce sont toutes des propriétés structurelles et sont orthogonales au sujet. Le déclaratif ne concerne pas "quoi et comment" . Nous pouvons déclarer (représenter et contraindre) un "comment" aussi facilement que nous déclarons un "quoi" . Le déclaratif concerne la structure, pas le contenu. La programmation déclarative a un impact significatif sur la façon dont nous abstrayons et refacturons notre code et sur la façon dont nous le modularisons en sous-programmes, mais pas tellement sur le modèle de domaine.
Souvent, nous pouvons convertir d’impératif en déclaratif en ajoutant un contexte. Par exemple. de "Tournez à gauche. (... attendez ...) Tournez à droite." to "Bob tournera à gauche à l'intersection de Foo et Bar à 11h01. Bob tournera à droite à l'intersection de Bar et Baz à 11h06." Notez que dans le dernier cas, les phrases sont idempotentes et commutatives, alors que dans le premier cas, réorganiser ou répéter les phrases changerait gravement le sens du programme.
Concernant monotone , les déclarations peuvent ajouter des contraintes auxquelles soustraire possibilités . Mais les contraintes ajoutent toujours des informations (plus précisément, les contraintes sont des informations). Si nous avons besoin de déclarations variant dans le temps, il est typique de les modéliser avec une sémantique temporelle explicite - par ex. de "la balle est à plat" à "la balle est à plat au temps T". Si nous avons deux déclarations contradictoires, nous avons un système déclaratif incohérent, bien que cela puisse être résolu en introduisant des contraintes souples (priorités, probabilités, etc.) ou en tirant parti d'une logique paraconsistante.
La programmation déclarative est "l'acte de programmer dans des langages conformes au modèle mental du développeur plutôt qu'au modèle opérationnel de la machine".
La différence entre programmation déclarative et impérative est bien illustrée par le problème de l'analyse de données structurées.
Un programme impératif utiliserait des fonctions mutuellement récursives pour consommer des entrées et générer des données. Un programme déclaratif exprimerait une grammaire qui définit la structure des données pour pouvoir ensuite les analyser.
La différence entre ces deux approches réside dans le fait que le programme déclaratif crée un nouveau langage qui correspond plus étroitement au modèle mental du problème que son langage hôte.
Cela peut sembler étrange, mais j'ajouterais Excel (ou tout tableur en réalité) à la liste des systèmes déclaratifs. Un bon exemple de ceci est donné ici .
Je l'expliquerais comme DP est un moyen d'exprimer
- A expression d'objectif, les conditions pour ce que nous recherchons. Y en a-t-il un, peut-être ou plusieurs?
- Quelques faits connus
- Règles qui étendent les faits connus
... et où il existe un moteur de déduction fonctionnant généralement avec un algorithme nification pour trouver les objectifs.