Nous concevons un langage de programmation multi-paradigme. Partie 5 - Caractéristiques de la programmation logique

Nous continuons l'histoire de la création d'un langage de programmation multi-paradigme qui combine un style logique déclaratif avec un style orienté objet et fonctionnel, ce qui serait pratique lorsque vous travaillez avec des données semi-structurées et intégrez des données provenant de sources disparates. Le langage sera constitué de deux composants étroitement intégrés l'un à l'autre: le composant déclaratif sera chargé de décrire le modèle de domaine, et le composant impératif ou fonctionnel sera chargé de décrire les algorithmes pour travailler avec le modèle et le calcul.



Dans le dernier articleJ'ai commencé mon histoire sur le composant de modélisation de langage hybride. C'est un ensemble de concepts-objets reliés par des relations logiques. J'ai réussi à parler des principaux moyens de définir les concepts, l'héritage et de définir la relation entre eux. Les raisons qui m'ont poussé à commencer à concevoir un langage hybride, et ses fonctionnalités, se trouvent dans mes publications précédentes sur ce sujet. Des liens vers eux se trouvent à la fin de cet article.



Et maintenant je propose de plonger dans certaines des nuances de la programmation logique. Puisque le langage du composant de modélisation a une forme logique déclarative, il sera nécessaire de résoudre des problèmes tels que la définition de la sémantique de l'opérateur de négation, l'introduction d'éléments de logique d'ordre supérieur et l'ajout de la possibilité de travailler avec des variables logiques. Et pour ce faire, vous devrez faire face à des problèmes théoriques tels que l'hypothèse de l'ouverture / fermeture du monde, le déni comme refus, une sémantique de modèle stable et une sémantique bien fondée. Et aussi avec la façon dont les possibilités de la logique d'ordre supérieur sont implémentées dans d'autres langages de programmation logiques.

Commençons par les variables booléennes

Dans la plupart des langages de programmation logique, les variables sont utilisées comme désignation symbolique (espace réservé) d'instructions arbitraires. Ils se produisent aux positions des arguments des prédicats et relient les prédicats les uns aux autres. Par exemple, dans la règle suivante du langage Prolog, les variables jouent le rôle d'objets X et Y , reliés par des relations: frère , parent , mâle et inégalité:

brothers(X,Y) :- parent(Z,X), parent(Z,Y), male(X), male(Y), X\=Y.
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

Dans le composant de modélisation, le rôle des arguments de terme est principalement joué par les attributs de concept:

concept brothers (person1, person2) FROM
parent p1 (child = person1),
parent p2 (child = person2),
male(person: person1),
male(person: person2)
WHERE p1.parent = p2.parent AND person1 != person2
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

Ils sont accessibles directement par nom, comme en SQL. Bien que la syntaxe proposée semble plus lourde par rapport à Prolog, dans le cas d'un grand nombre d'attributs, cette option sera plus pratique, car elle met l'accent sur la structure de l'objet.



Mais dans certains cas, il serait toujours pratique de déclarer une variable booléenne qui ne serait incluse dans les attributs d'aucun des concepts, mais qui serait en même temps utilisée dans l'expression des relations. Par exemple, si une sous-expression a une forme complexe, vous pouvez la décomposer en ses composants en les liant à des variables booléennes. De plus, si une sous-expression est utilisée plusieurs fois, vous ne pouvez la déclarer qu'une seule fois en l'associant à une variable. Et à l'avenir, utilisez une variable au lieu d'une expression. Afin de distinguer les variables booléennes des attributs de concept et des variables des composants de calcul, décidons que les noms de variables booléennes doivent commencer par le symbole $ .

A titre d'exemple, nous pouvons analyser le concept qui spécifie l'appartenance d'un point à un anneau, qui est décrit par les rayons extérieur et intérieur. La distance d'un point au centre d'un anneau peut être calculée une fois, liée à une variable et comparée aux rayons:

relation pointInRing between point p, ring r 
where $dist <= r.rOuter 
    and $dist >= r.rInner 
    and $dist = Math.sqrt((p.x – r.x) * (p.x – r.x) + (p.y – r.y) * (p.y – r.y))
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

En même temps, cette distance elle-même a un rôle auxiliaire et ne fera pas partie du concept.

Négation.

Examinons maintenant un problème plus complexe - l'implémentation de l'opérateur de négation dans le composant de modélisation. Les systèmes de programmation logique incluent généralement, en plus de l'opérateur de négation booléenne, la règle de négation en tant que refus. Il vous permet d'imprimer not p si la dérivation de p échoue . Dans différents systèmes de représentation des connaissances, le sens et l'algorithme de la règle pour l'inférence de la négation peuvent différer.



Premièrement, il est nécessaire de répondre à la question sur la nature du système de connaissances en termes d'exhaustivité. Dans les systèmes qui adhèrent à "l'hypothèse du monde ouvert" , la base de connaissances est considérée comme incomplète, de sorte que les déclarations qui en manquent sont considérées comme inconnues. Pas une affirmation ne peut être généré que si la base de connaissances stocke explicitement l'instruction que pfaux. Un tel déni est appelé fort. Les déclarations manquantes sont considérées comme inconnues et non fausses. Un exemple de système de connaissances utilisant une telle hypothèse est le WEB sémantique. Il s'agit d'un réseau sémantique mondial accessible au public formé sur la base du World Wide Web. Les informations qu'il contient sont, par définition, incomplètes - elles ne sont pas entièrement numérisées et traduites sous une forme lisible par machine, elles sont réparties entre différents nœuds et sont constamment complétées. Par exemple, si sur Wikipédia, dans un article sur Tim Berners-Lee, le créateur du World Wide Web et l'auteur du concept de Web sémantique, rien n'est dit sur ses préférences culinaires, cela ne veut pas dire qu'il ne les a pas, l'article est tout simplement incomplet.



L'hypothèse opposée est «l'hypothèse que le monde est fermé».... On pense que dans de tels systèmes, la base de connaissances est complète et les déclarations manquantes sont considérées comme inexistantes ou fausses. La plupart des bases de données suivent cette hypothèse. Si la base de données ne contient pas d'enregistrement sur une transaction ou sur un utilisateur, nous sommes sûrs qu'une telle transaction n'existait pas et que l'utilisateur n'est pas enregistré dans le système (au moins toute la logique du système est basée sur le fait qu'ils n'existent pas).



Les bases de connaissances complètes ont leurs avantages. Premièrement, il n'est pas nécessaire de coder des informations inconnues - une logique à deux valeurs (vrai, faux) est suffisante au lieu de trois valeurs (vrai, faux, inconnu). Deuxièmement, vous pouvez combiner l'opérateur de négation booléen et la vérification de la dérivabilité d'une instruction de la base de connaissances en un opérateur de négation en tant que refus(négation comme échec). Il renverra true non seulement si l'instruction selon laquelle l'instruction est fausse est stockée, mais également s'il n'y a aucune information à ce sujet dans la base de connaissances. Par exemple, la

règle



p <— not q





déduit que q est faux (car il n'y a aucune déclaration indiquant que c'est vrai) et p est vrai.



Malheureusement, la sémantique du déni en tant que rejet n'est pas aussi évidente et compliquée qu'il n'y paraît. Dans différents systèmes de programmation logique, sa signification a ses propres caractéristiques. Par exemple, dans le cas des définitions cycliques:

p ← not q
q ← not p
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

la résolution SLDNF classique (SLD + Negation as Failure) utilisée dans le langage Prolog échouera. La sortie de l'instruction p nécessite la sortie de q , et q - dans p , la procédure de sortie tombera dans une boucle infinie. Dans Prolog, ces définitions sont considérées comme non valides et la base de connaissances est considérée comme incohérente.



En même temps, ces déclarations ne sont pas un problème pour nous. Intuitivement, nous comprenons ces deux règles comme disant que p et qont des significations opposées, si l'une d'elles est vraie, alors l'autre est fausse. Par conséquent, il est souhaitable que l'opérateur de la négation en tant que refus puisse travailler avec de telles règles, de sorte que les constructions de programmes logiques soient plus naturelles et compréhensibles pour une personne.



En outre, la cohérence de la base de connaissances n'est pas toujours réalisable. Par exemple, parfois, les définitions de règles sont délibérément séparées des faits afin que le même ensemble de règles puisse être appliqué à différents ensembles de faits. Dans ce cas, rien ne garantit que les règles concorderont avec tous les ensembles de faits possibles. Il est également parfois acceptable que les règles elles-mêmes ne soient pas cohérentes, par exemple si elles sont rédigées par des experts différents.



Les campagnes les plus connues, permettent de formaliser la conclusion logique sous les définitions cycliques et les incohérences du programme sont la «sémantique durable» (sémantique du modèle stable) et la «sémantique raisonnable» (la sémantique bien fondée).



La règle d'inférence avec une sémantique de modèle persistante est basée sur l'hypothèse que certains opérateurs de négation dans un programme peuvent être ignorés s'ils ne sont pas cohérents avec le reste du programme. Puisqu'il peut y avoir plusieurs de ces sous-ensembles cohérents de l'ensemble initial de règles, il peut y avoir plusieurs solutions, respectivement. Par exemple, dans la définition ci-dessus, l'inférence peut commencer par la première règle ( p ← pas q ), écarter le second ( q ← pas p ) et obtenir la solution {p, pas q} . Et puis faites de même pour le second et obtenez {q, pas p} . La solution globale sera un ensemble combiné de solutions alternatives. Par exemple, à partir des règles:

person(alex)
alive(X) ←person(X)
male(X) ←person(X) AND NOT female(X)
female(X) ←person(X) AND NOT male(X)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

nous pouvons afficher deux options de réponse: {personne (alex), vivant (alex), homme (alex)} et {personne (alex), vivant (alex), femme (alex)} .

La sémantique raisonnable commence avec les mêmes hypothèses, mais cherche à trouver une solution partielle générale qui satisfait tous les sous-ensembles consensuels alternatifs de règles. Une solution partielle signifie que les valeurs «vrai» ou «faux» ne seront affichées que pour une partie des faits, et les valeurs du reste resteront inconnues. Ainsi, dans la description des faits dans le programme, une logique à deux valeurs est utilisée et, dans le processus d'inférence, à trois valeurs. Pour les règles considérées ci-dessus, les significations de p et qsera inconnu. Mais, par exemple, pour

p ← not q
q ←not p
r ← s
s
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

nous pouvons en déduire avec certitude que r et s sont vrais, bien que p et q restent inconnus.



Par exemple, à partir de l'exemple alex, nous pourrions déduire {personne (alex), vivante (alex)} , tandis que les déclarations male (alex) et female {alex} restent inconnues.



En SQL, la négation booléenne ( NOT ) et la vérification de la dérivabilité ( NOT EXISTS) sont séparés. Ces opérateurs s'appliquent à différents types d'arguments: NOT inverse une valeur booléenne, et EXISTS / NOT EXISTS vérifie le résultat d'une requête imbriquée pour la vacuité, donc cela n'a aucun sens de les combiner. La sémantique des opérateurs de négation en SQL est très simple et n'est pas conçue pour fonctionner avec des requêtes incohérentes récursives ou complexes; avec une compétence SQL spéciale, la requête peut être envoyée à une récursivité infinie. Mais les constructions logiques complexes sont clairement en dehors de la portée traditionnelle de SQL, il n'a donc pas besoin d'une sémantique d'opérateur de négation sophistiquée.



Essayons maintenant de comprendre la sémantique des opérateurs de négation du composant de modélisation du langage hybride conçu.



Premièrement, le composant de modélisation est conçu pour intégrer des sources de données disparates. Ils peuvent être très variés et être complets ou incomplets. Par conséquent, des opérateurs de contrôle de dérivabilité sont absolument nécessaires.



Deuxièmement, la forme des concepts de composants de modélisation est beaucoup plus proche des requêtes SQL que des règles de programmation logique. Le concept a également une structure complexe, donc mélanger dans un opérateur de négation booléenne et vérifier la dérivabilité du concept n'a pas de sens. La négation booléenne n'a de sens que pour s'appliquer aux attributs, aux variables et aux résultats d'expression - ils peuvent être faux ou vrais. Il est plus difficile de l'appliquer à un concept, il peut se composer de différents attributs et il n'est pas clair lequel d'entre eux devrait être responsable de la fausseté ou de la vérité du concept dans son ensemble. Le concept peut être dérivé des données initiales dans leur ensemble, et non de ses attributs individuels. Contrairement à SQL, où la structure des tables est fixe, la structure des concepts peut être flexible, un concept peut ne pas avoir du tout l'attribut requis dans sa composition,donc une vérification de l'existence de l'attribut est également nécessaire.



Par conséquent, il est judicieux d'introduire des opérateurs distincts pour chaque type de négation répertorié ci-dessus. La fausseté des attributs peut être vérifiée à l'aide de l'opérateur booléen NOT traditionnel , si un concept contient un attribut à l'aide de la fonction intégrée DEFINED et le résultat de l'inférence du concept à partir des données d'origine à l'aide de la fonction EXISTS . Les trois opérateurs distincts sont plus prévisibles, compréhensibles et plus faciles à utiliser que l'opérateur complexe de négation en tant que défaillance. Si nécessaire, ils peuvent être combinés en un seul opérateur d'une manière ou d'une autre qui convient à chaque cas spécifique.



Troisièmement, pour le moment, le composant de modélisation est considéré comme un outil de création de petites ontologies au niveau des applications. Il est peu probable que son langage ait besoin d'une expressivité logique spéciale et de règles d'inférence sophistiquées capables de gérer les définitions récursives et les incohérences logiques du programme. Par conséquent, la mise en œuvre de règles d'inférence complexes basées sur la sémantique de modèles persistants ou une sémantique ancrée ne semble pas souhaitable, du moins à ce stade. La résolution SLDNF classique devrait suffire.



Regardons maintenant quelques exemples.



Un concept peut recevoir une signification négative si certains de ses attributs ont une signification qui l'indique. La négation des attributs vous permet de trouver explicitement de telles entités:

concept unfinishedTask is task t where not t.completed
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

La fonction de vérification de l'ambiguïté d'un attribut sera pratique si les entités d'un concept peuvent avoir des structures différentes:

concept unassignedTask is task t where not defined(t.assignedTo) or empty(t.assignedTo)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

La fonction de vérification de la déductibilité d'un concept est irremplaçable lorsque l'on travaille avec des définitions récursives et des structures hiérarchiques:

concept minimalElement is element greater 
where not exists(element lesser where greater.value > lesser.value)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

Dans cet exemple, la vérification de l'existence d'un élément plus petit est effectuée en tant que sous-requête. Je prévois d'étudier en détail la création de requêtes imbriquées dans la prochaine publication.

Éléments de logique d'ordre supérieur

Dans la logique du premier ordre, les variables ne peuvent correspondre qu'à des ensembles d'objets et n'apparaissent qu'aux positions des arguments des prédicats. Dans la logique d'ordre supérieur, ils peuvent également correspondre à des ensembles de relations et apparaître à la position des noms de prédicat. En d'autres termes, la logique du premier ordre permet d'affirmer qu'une relation est vraie pour tout ou partie des objets. Et la logique d'ordre supérieur consiste à décrire la relation entre les relations.



Par exemple, nous pouvons affirmer que certaines personnes sont des frères, sœurs, enfants ou parents, oncles ou tantes, etc.

Brother(John, Joe).
Son(John, Fred).
Uncle(John, Alex).
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

Mais pour faire une assertion de relation, dans la logique du premier ordre, nous devons lister toutes les instructions ci-dessus, en les combinant à l'aide de l'opération OR:

ⱯX,ⱯY(Brother(X, Y) OR Brother(Y, X) OR Son(X, Y) OR Son(Y, X) OR Uncle(X, Y) OR Uncle(Y, X) → Relative(X, Y)).
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

La logique du second ordre vous permet de faire une déclaration sur d'autres déclarations. Par exemple, on pourrait dire directement que la relation entre frères, sœurs, parents et enfants, oncles et neveux est une relation de parenté:

RelativeRel(Brother).
RelativeRel(Son).
RelativeRel(Uncle).
ⱯX,ⱯY(ⱻR(RelativeRel(R) AND (R(X, Y) OR R(Y, X))) → Relative(X, Y)).
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

Nous soutenons que si pour chaque X et Y il existe une relation R qui est une relation entre des frères et sœurs RelativeRel , et que X et Y satisfont cette relation, alors X et Y sont des frères et sœurs. Les arguments de relation peuvent être d'autres relations et des variables peuvent être remplacées par des noms de relations.



La logique du troisième ordre vous permet de construire des déclarations sur les déclarations sur les déclarations, et ainsi de suite, la logique d'ordre supérieur- sur les déclarations de tout niveau d'imbrication. La logique d'ordre supérieur est beaucoup plus expressive, mais aussi beaucoup plus complexe. En pratique, les systèmes de programmation logique ne prennent en charge que certains de ses éléments, qui se limitent principalement à l'utilisation de variables et d'expressions arbitraires aux positions des prédicats.



Dans Prolog, les éléments d'une telle logique sont implémentés à l'aide de plusieurs méta-prédicats intégrés, dont les arguments sont d'autres prédicats. Le principal est l' appel de prédicat qui vous permet d'ajouter dynamiquement des prédicats à la liste cible de la règle actuelle. Son premier argument est traité comme le but et le reste comme ses arguments. Prolog recherchera dans la base de connaissances les prédicats correspondant au premier argument et les ajoutera à la liste cible actuelle. Un exemple avec des proches ressemblerait à ceci:

brother(john, jack).
sister(mary, john).
relative_rel(brother).
relative_rel(sister).
relative(X, Y) :- relative_rel(R), (call(R, X, Y); call(R, Y, X)).
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

Prolog prend également en charge les prédicats findall (Template, Goal, Bag) , bagof (Template, Goal, Bag) , setof (Template, Goal, Set) , etc., qui vous permettent de trouver toutes les solutions d'objectif Goal qui correspondent au Template et unifier (lien) leur liste avec le résultat Sac (ou Set ). Prolog a des prédicats intégrés current_predicate , clause et autres pour rechercher des prédicats dans la base de connaissances. Vous pouvez également manipuler les prédicats et leurs attributs dans les bases de connaissances - les ajouter, les supprimer et les copier.



Le langage HiLog prend en charge la logique d'ordre supérieur au niveau de la syntaxe. Au lieu de méta-prédicats spéciaux, il permet d'utiliser des termes arbitraires (tels que des variables) directement à la position des noms de prédicat. La règle de détermination des parents prendra la forme:

relative(X, Y) :- relative_rel(R), (R(X, Y); R(Y, X)).
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

Cette syntaxe est plus déclarative, concise, compréhensible et naturelle par rapport à Prolog. Dans le même temps, HiLog reste une variante syntaxique de Prolog, puisque toutes les constructions syntaxiques HiLog peuvent être transformées en expressions logiques de premier ordre à l'aide des méta-prédicats d' appel .



HiLog est considéré comme ayant une syntaxe d'ordre supérieur , mais une sémantique de premier ordre . Cela signifie que lors de la comparaison de variables qui représentent des règles ou des fonctions, seuls leurs noms sont pris en compte, pas leur implémentation. Il existe également des langages qui prennent en charge la sémantique d'ordre supérieur, tels que λ-Prolog, qui permettent également d'implémenter des règles et des fonctions dans le processus d'inférence. Mais cette logique et ses algorithmes d'inférence sont beaucoup plus compliqués.



Passons maintenant à la fonctionnalité logique d'ordre supérieur du composant de modélisation . Pour la plupart des tâches de méta-programmation pratiques, Prolog et HiLog devraient suffire. HiLog a une syntaxe plus naturelle, il est donc logique de la prendre comme base. Pour pouvoir utiliser des expressions arbitraires sur les positions des noms de concepts et de leurs attributs et pour les distinguer des variables, appels de fonctions et autres constructions, nous introduisons un opérateur spécial pour spécifier dynamiquement les noms :

< >







Il vous permet d'évaluer la valeur d'une expression et de l'utiliser comme nom de concept, alias ou nom d'attribut, selon le contexte. Si cet opérateur se place à la place du nom du concept dans la section FROM et que la valeur de son expression est définie, alors tous les concepts avec le nom spécifié seront trouvés et une recherche logique est effectuée pour eux:

concept someConcept ( … ) from conceptA a, <a.conceptName> b where …





Si la valeur de l'expression n'est pas définie, par exemple, l'expression est une variable booléenne non associée à la valeur , alors la procédure trouvera tous les concepts appropriés et associera la valeur de la variable à leurs noms:

concept someConcept is <$conceptName> where …





On peut dire que dans le contexte de la section FROM , l' opérateur pour spécifier un nom a une sémantique logique .

De plus, l'opérateur <> peut être utilisé et les clauses WHERE à la position d'un alias de concept ou d'un nom d'attribut:

concept someConcept ( … ) from conceptA a, conceptB b where conceptB.<a.foreignKey> = a.value ...
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

Les expressions de la clause WHERE sont déterministes, c'est-à-dire qu'elles n'utilisent pas la recherche logique pour trouver des valeurs inconnues pour leurs arguments. Cela signifie que l'expression conceptB. <A.foreignKey> = a.value ne sera évaluée qu'après avoir trouvé les entités du concept a et que ses attributs ForeignKey et value seront associés à des valeurs. Par conséquent, nous pouvons dire que dans le contexte de la clause FROM , l'instruction de nom a une sémantique fonctionnelle .



Considérons quelques applications possibles de la logique d'ordre supérieur.

L'exemple le plus évident où la logique d'ordre supérieur conviendra est l'union sous un seul nom de tous les concepts qui satisfont à certaines conditions. Par exemple, avoir certains attributs. Ainsi, le concept de point peut être considéré comme tous les concepts qui incluent les coordonnées x et y :

concept point is <$anyConcept> a where defined(a.x) and defined(a.y)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

La recherche booléenne liera la variable $ anyConcept avec tous les noms de concept déclarés (sauf bien sûr lui-même) qui ont des attributs de coordonnées.



Un exemple plus complexe serait de déclarer une relation générale qui s'applique à de nombreux concepts. Par exemple, une relation parent-enfant transitive entre des concepts:

relation ParentRel between <$conceptName> parent, <$conceptName> child
where defined(parent.id) and defined(child.parent) and (
parent.id = child.parent or exists(
	<$conceptName> intermediate where intermediate.parent = parent.id 
            and ParentRel(intermediate, child)	
))
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

La variable $ conceptName est utilisée dans les trois concepts de parent, enfant et intermédiaire, ce qui signifie que leurs noms doivent être identiques.



La logique d'ordre supérieur ouvre des possibilités de programmation générique dans le sens où vous pouvez créer des concepts et des relations génériques qui peuvent être appliqués à une variété de concepts qui satisfont des conditions données sans être liés à leurs noms spécifiques.



En outre, la substitution de nom dynamique sera pratique dans les cas où les attributs d'un concept sont des références aux noms d'autres concepts ou à leurs attributs, ou lorsque les données source contiennent non seulement des faits, mais également leur structure. Par exemple, les données source peuvent inclure une description des schémas de documents XML ou de tables dans une base de données. Les données d'origine peuvent également inclure des informations supplémentaires sur les faits, par exemple, les types de données, les formats ou les valeurs par défaut, les conditions de validation ou certaines règles. En outre, les données initiales peuvent décrire le modèle de quelque chose, et le composant de modélisation sera responsable de la construction du métamodèle. Travailler avec des textes en langage naturel suppose également que les données source comprendront non seulement des déclarations, mais également des déclarations sur des déclarations.Dans tous ces cas, la logique du premier ordre ne suffira pas et un langage plus expressif est nécessaire.



À titre d'exemple simple, considérons le cas où les données incluent certains objets, ainsi que les règles de validation des attributs de ces objets en tant qu'entité distincte:

fact validationRule {objectName: “someObject”, attributeName: “someAttribute”, rule: function(value) {...}}
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

Les résultats de la validation peuvent être décrits par le concept suivant:

concept validationRuleCheck (
	objectName = r.objectName,
	attributeName = r.attrName,
	result = r.rule(o.<r.attrName>)
) from validationRule r, <r.objectName> o 
where defined(o.<r.attrName>)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

La logique d'ordre supérieur ouvre des possibilités assez intéressantes pour la généralisation et la méta-programmation. Nous n'avons pu considérer que son idée générale. Ce domaine est assez complexe et nécessite des recherches approfondies à l'avenir. À la fois du point de vue du choix d'une conception pratique de la langue et des problèmes de ses performances.

conclusions

Dans le processus de travail sur le composant de modélisation, j'ai dû faire face à des problèmes assez spécifiques de programmation logique, tels que le travail avec des variables booléennes, la sémantique de l'opérateur de négation et des éléments de logique d'ordre supérieur. Si tout s'est avéré assez simple avec des variables, il n'y a pas d'approche unique bien établie pour la mise en œuvre de l'opérateur de négation et de la logique d'ordre supérieur, et il existe plusieurs solutions qui ont leurs propres caractéristiques, avantages et inconvénients.



J'ai essayé de choisir une solution qui serait facile à comprendre et pratique dans la pratique. J'ai préféré scinder l'opérateur de négation monolithique comme un refus en trois opérateurs distincts de négation booléenne, vérifiant la déductibilité d'un concept et l'existence d'un attribut dans un objet. Si nécessaire, ces trois opérateurs peuvent être combinés pour obtenir la sémantique de négation requise pour chaque cas spécifique. Pour la règle de négation de l'inférence, j'ai décidé de prendre la résolution SLDNF standard comme base. Bien qu'il ne soit pas capable de traiter des déclarations récursives incohérentes, il est beaucoup plus facile à comprendre et à implémenter que des alternatives plus sophistiquées telles que la sémantique de modèle persistante ou la sémantique raisonnée.



Une logique d'ordre supérieur est nécessaire pour la généralisation et la méta-programmation. Par programmation générique, j'entends la capacité de construire de nouveaux concepts à partir d'une grande variété de concepts enfants sans être lié à des noms spécifiques de ces derniers. Par méta-programmation, j'entends la capacité de décrire la structure de certains concepts à l'aide d'autres concepts. J'ai décidé de prendre le langage HiLog comme modèle pour les éléments logiques d'ordre supérieur du composant de modélisation. Il a une syntaxe flexible et pratique qui vous permet d'utiliser des variables aux positions des noms de prédicat, ainsi qu'une sémantique simple et claire.



Le prochain article que je compte consacrer à l'emprunt dans le monde de SQL: requêtes imbriquées et agrégations. Je parlerai également d'un autre type de concepts qui n'utilise pas l'inférence, mais à la place, les entités sont directement générées à l'aide d'une fonction donnée. Et comment vous pouvez l'utiliser pour convertir des tables, des tableaux et des tableaux associatifs au format objet et les inclure dans le processus d'inférence logique (par analogie avec l'opération SQL UNNEST, qui convertit les tableaux au format de table).



Le texte intégral en style scientifique en anglais est disponible ici .



Liens vers les publications précédentes:



Conception d'un langage de programmation multi-paradigme. Partie 1 - À quoi ça sert?

Nous concevons un langage de programmation multi-paradigme. Partie 2 - Comparaison des modèles de construction en PL / SQL, LINQ et GraphQL Nous

concevons un langage de programmation multi-paradigmes. Partie 3 - Vue d'ensemble des langages de représentation des connaissances Nous

concevons un langage de programmation multi-paradigmes. Partie 4 - Constructions de base du langage de modélisation