Nous concevons un langage de programmation multi-paradigme. Partie 6 - Emprunter depuis SQL

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.



Le composant de modélisation de langage hybride 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, y compris l'héritage et la définition des relations entre eux. Et aussi sur certaines des nuances de la programmation logique, y compris la sémantique de l'opérateur de négation et la logique d'ordre supérieur. Une liste complète des publications sur ce sujet se trouve à la fin de cet article.



Dans le domaine du travail avec des données, le leader incontestable est le langage SQL. Certaines de ses fonctionnalités, qui se sont avérées très pratiques en pratique, comme l'agrégation, ont ensuite migré vers la programmation logique. Par conséquent, il sera utile d'emprunter autant que possible à SQL pour le composant de modélisation. Dans cet article, je souhaite vous montrer comment les requêtes imbriquées, les jointures externes et l'agrégation peuvent être intégrées dans les définitions de concept. Je parlerai également d'un autre type de concepts, qui est décrit à l'aide d'une fonction qui génère des objets (entités) dans un style algorithmique sans recourir à la recherche logique. Et je vais vous montrer comment vous pouvez utiliser des tableaux d'objets comme concepts parents par analogie avec l'opération SQL UNNESTqui convertit les collections au format table et leur permet d'être jointes à d'autres tables dans la clause FROM .

Définitions anonymes des concepts

Dans le monde SQL, les requêtes imbriquées sont un outil souvent utilisé lorsqu'il est nécessaire d'obtenir des données intermédiaires pour un traitement ultérieur dans la requête principale. Le composant de modélisation n'a pas un besoin aussi urgent de données intermédiaires, car la manière de les obtenir peut être formalisée en tant que concept séparé. Mais il y a des cas où des définitions de concept imbriquées seraient utiles.



Parfois, vous devez modifier légèrement le concept, sélectionner ses attributs individuels, filtrer les valeurs. Si cette modification n'est nécessaire qu'à un seul endroit, cela n'a aucun sens de créer un concept séparé avec un nom unique. Cette situation est souvent rencontrée lorsque les concepts sont des arguments pour des fonctions telles que exist , find ou findOne , qui vérifie la déductibilité du concept, en trouvant tout ou seulement le premier objet (entité) du concept. Ici, vous pouvez faire une analogie avec les fonctions anonymes dans les langages de programmation fonctionnelle, qui sont souvent utilisées comme arguments pour des fonctions telles que mapper , rechercher , filtrer , etc.



Considérez la syntaxe pour définir un concept anonyme. En général, il suit la syntaxe d'une définition de concept commune, sauf que dans certains cas, vous pouvez omettre les listes d'attributs et le nom du concept enfant. Si un concept anonyme est utilisé comme argument pour existe, alors son nom et la liste des attributs ne sont pas importants, il suffit de vérifier qu'il y a au moins un résultat. Les fonctions find et findOne peuvent ne pas avoir besoin du nom du concept si la sortie n'est pas utilisée comme un concept entier, mais uniquement comme un ensemble d'attributs dans un tableau associatif. Si aucun attribut n'est spécifié, le mécanisme d'héritage est utilisé par défaut et les attributs seront hérités des concepts parents. Si aucun nom de concept n'est spécifié, il sera généré automatiquement.



Essayons d'expliquer ce qui a été écrit ci-dessus à l'aide de quelques exemples. À l'aide de la fonction Existe , vous pouvez vérifier la déductibilité ou la non-déductibilité d'un concept embarqué:

concept freeExecutor is executor e where not exists (
    task t where t.executor = e.id and t.status in ('assigned', 'in process')
)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

Dans cet exemple, le concept anonyme:

(task t where t.executor = e.id and t.status in ('assigned', 'in process'))
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

est en fait un concept qui hérite de tous les attributs du concept de tâche :

(concept _unanimous_task_1 as task t where t.executor = e.id and t.status in ('assigned', 'in process'))
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

La fonction find permet de renvoyer sous forme de liste toutes les valeurs d'un concept, qui peuvent ensuite être associées à un attribut:

concept customerOrdersThisYear is customer c with orders where c.orders = find(
    (id = o.id, status = o.status, createdDate = o.createdDate, total = o.total) 
    from order o where o.customerId = c.id and o.createdDate > '2021-01-01'
)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

Dans cet exemple, nous étendons la notion de client avec une liste de commandes, qui sont des objets contenant les attributs sélectionnés de la notion de commande . Nous avons spécifié une liste d'attributs pour un concept anonyme, mais son nom est omis.



Les conditions dans la section où les concepts anonymes peuvent inclure d' autres attributs des concepts de mère ou filiale, dans ce cas c.id . Une caractéristique des concepts anonymes est que toutes ces variables et attributs externes doivent nécessairement être associés à des valeurs au moment du démarrage de la recherche de solutions. Ainsi, les objets du concept anonyme ne peuvent être trouvés qu'après avoir trouvé les objets du concept client . ...

Connexions externes

Les définitions de concept anonymes peuvent également être utilisées dans la section from , où elles représentent des concepts parents. De plus, dans la définition d'un concept anonyme, il est possible de transférer certaines des conditions le reliant à d'autres concepts, ce qui aura un effet particulier. Ces conditions seront vérifiées au stade de la recherche d'une solution au concept anonyme et n'affecteront pas le processus d'inférence du concept enfant. Ici, vous pouvez dessiner une analogie entre les conditions de la section where d' un concept anonyme et les conditions de la section JOIN ON de SQL.



Ainsi, des concepts anonymes peuvent être utilisés pour implémenter un analogue SQL de jointure externe gauche. Cela nécessite trois choses.

1. Tout d'abord, remplacez le concept parent souhaité par un concept anonyme basé sur celui-ci et transférez-y toutes les connexions avec d'autres concepts parents.
2. Deuxièmement, souligner que l'échec de l'inférence de ce concept ne doit pas conduire à un échec automatique de l'inférence de l'ensemble du concept de l'enfant. Pour ce faire, vous devez marquer ce concept parent avec le mot-clé facultatif .
3. Et troisièmement, dans la section where du concept enfant, vous pouvez vérifier s'il existe des solutions à ce concept anonyme.

Regardons un petit exemple:

concept taskAssignedTo (task = t, assignee = u, assigneeName) 
from task t, optional (user where id = t.assignedTo) u 
where assigneeName = if(defined(u), u.firstName + ' ' + u.lastName, 'Unassigned') 
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

Les attributs du concept taskAssignedTo incluent les objets de la tâche, son exécuteur et séparément le nom de l'exécuteur. Les concepts parents sont tâche et utilisateur , et ce dernier peut être vide si la tâche n'a pas déjà d'exécuteur. Il est enveloppé dans une définition de concept anonyme, précédée du mot-clé facultatif . La procédure d'inférence va d' abord trouver des objets de la tâche notion , puis, en fonction de l' utilisateur, il va créer un concept anonyme, associant à une valeur spécifique de l' AssignedTo attribut de la tâche notion . Mot-clé optionnel indique à la routine d'inférence que si le concept échoue, son objet sera associé à la valeur spéciale UNDEFINED . Et vérifier le résultat de sa sortie au niveau du concept enfant permet à l'attribut assigneeName de définir une valeur par défaut. Si le mot clé facultatif n'était pas spécifié, l'échec de la déduction d'un concept anonyme entraînerait l'échec de la branche actuelle de la recherche de concept enfant. Ce serait analogue à la jointure interne de SQL.



Parce que les conditions dans le où la clause de la notion anonyme comprennent l' AssignedTo attribut de l' autre concept parent tâche , la recherche d'objets de l' utilisateur conceptuel n'est possible qu'après avoir lié des objets de tâche avec des valeurs. Ils ne peuvent pas être échangés:

from optional (user where id = t.assignedTo) u, task t 
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

Étant donné qu'au stade initial, la valeur de t.assignedTo sera inconnue, cela ne fonctionnera pas pour créer une définition d'un concept anonyme.



Si en SQL l'ordre des tables dans la section fromn'a pas d'importance, alors dans Prolog, l'ordre des prédicats dans une règle détermine de manière unique la séquence de traversée de l'arbre de décision. Il en va de même pour le composant de simulation, dont la règle de sortie est basée sur la résolution SLD utilisée dans Prolog. Dans celui-ci, le résultat de la sortie des objets du concept de gauche détermine les restrictions pour la sortie des objets du concept de droite. Pour cette raison, malheureusement, il ne fonctionnera pas pour implémenter les opérations de jointure externe et de jointure externe complètes de la même manière naturelle. Étant donné que la cardinalité de l'ensemble des résultats du concept de parent droit peut être supérieure à celle du concept de gauche, ils devront sortir dans la direction opposée - du concept droit vers la gauche. Malheureusement, les particularités de la procédure d'inférence choisie imposent leurs limites à la fonctionnalité du langage. Mais l'opération de jointure externe complète peut être émulée en rejoignant l'intérieur,unions gauche et droite:

concept outerJoinRelation( 
concept1Name, 
concept2Name, 
concept1Key,
concept2Key,
concept1 = c1,
concept2 = c2
) from <concept1Name> c1, <concept2Name> c2
where c1.<concept1Key> = c2.<concept2Key>;

concept outerJoinRelation(
concept1Name, 
concept2Name, 
concept1Key,
concept2Key,
concept1 = c1,
concept2 = null
) from <concept1Name> c1
where not exists( <concept2Name> c2 where c1.<concept1Key> = c2.<concept2Key>);

concept outerJoinRelation(
concept1Name, 
concept2Name, 
concept1Key,
concept2Key,
concept1 = null,
concept2 = c2
) from <concept2Name> c2
where not exists( <concept1Name> c1 where c1.<concept1Key> = c2.<concept2Key>);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

Ce concept généralisé est décrit à l'aide de la logique d'ordre supérieur décrite dans l' article précédent . Sa définition est divisée en trois parties. Le premier trouvera des intersections de concepts, le second - des objets que possède le concept de gauche et celui de gauche pas, et le troisième - vice versa. Puisque les noms de chaque partie sont les mêmes, les résultats de leur inférence seront combinés.

Agrégation

L'agrégation fait partie intégrante de l'algèbre relationnelle et de la programmation logique. En SQL, la clause GROUP BY vous permet de regrouper les lignes qui ont la même valeur de clé dans des lignes récapitulatives. Il vous permet de supprimer les valeurs en double et est couramment utilisé avec des fonctions d'agrégation telles que sum , count , min , max , avg.... Pour chaque groupe de lignes, les fonctions d'agrégation renvoient une valeur ordinaire basée sur toutes les lignes de ce groupe. En programmation logique, l'agrégation a une sémantique plus complexe. Cela est dû au fait que dans certains cas de définition récursive des règles SLD, la résolution entre dans une boucle infinie et ne peut pas se terminer. Comme dans le cas du refus comme échec, le problème de la récursivité dans l'opération d'agrégation est résolu en utilisant une sémantique de modèle persistante ou une sémantique bien fondée. J'ai essayé de parler brièvement de ces approches dans l' article précédent . Mais comme la sémantique du composant de modélisation doit être aussi simple que possible, la résolution SLD standard est préférée. Et le problème d'éviter la récursion infinie est mieux résolu en reformant les connexions entre les concepts.



L'agrégation pourrait naturellement être implémentée dans un style fonctionnel en utilisant le composant de calcul d'un langage hybride. Pour ce faire, une fonction qui regroupe les résultats d'inférence en groupes uniques et calcule les fonctions d'agrégation pour chacun d'entre eux est suffisante. Mais diviser la définition d'un concept en parties logiques et fonctionnelles ne sera pas la solution la plus pratique pour un outil aussi important que l'agrégation. Mieux vaut étendre la syntaxe de la définition pour inclure une section de regroupement et des fonctions d'agrégation:

concept < > < > (
    < > = <>,
    ... 
)
group by < >, ... 
from 
    <  > <  > (
        < > = <> ,
        ...
    ),
    ...
where < >
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

Le groupe par section , tout comme en SQL, contient une liste d'attributs par lesquels le regroupement est effectué. Les expressions de relation peuvent également inclure des fonctions d'agrégation. Les expressions contenant de telles fonctions seront considérées comme non définies jusqu'à ce que les valeurs de tous les concepts parents soient trouvées et que le regroupement soit effectué. Ensuite, leurs valeurs peuvent être calculées pour chaque groupe, associées à des attributs et / ou utilisées pour filtrer les groupes. Avec cette approche paresseuse pour évaluer et vérifier les conditions, il n'est pas nécessaire de disposer d'une section HAVING séparant les conditions de filtre avant et après le regroupement. Le runtime le fera automatiquement.



Les principales fonctions d'agrégation sont count , sum, moy , min , max . Le but des fonctions peut être compris à partir de leurs noms. Étant donné que le composant de modélisation peut naturellement fonctionner avec des types de données composites, vous pouvez également ajouter une fonction qui renvoie des valeurs groupées sous forme de liste. Appelons ça groupe . Son argument d'entrée est une expression. La fonction renvoie une liste des résultats de l'évaluation de cette expression pour chaque élément du groupe. En le combinant avec d'autres fonctions, vous pouvez implémenter n'importe quelle fonction d'agrégation arbitraire. La fonction de groupe sera plus pratique que les fonctions SQL telles que group_concat ou json_arrayagqui sont souvent utilisées comme étape intermédiaire pour obtenir un tableau de valeurs de champ.



Exemple de regroupement:

concept totalOrders (
    customer = c,
    orders = group(o),
    ordersTotal = sum(o.total)
) group by customer
from customer c, order o 
where c.id = o.customerId and ordersTotal > 100
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

L'attribut orders contiendra une liste de toutes les commandes des utilisateurs, ordersTotal - le total de toutes les commandes. La condition ordersTotal> 100 sera vérifiée une fois le regroupement effectué et la fonction de somme calculée .

Concept défini par la fonction

La forme logique déclarative de la description des concepts n'est pas toujours pratique. Parfois, il sera plus pratique de définir une séquence de calculs dont le résultat sera l'essence même du concept. Cette situation se produit souvent lorsqu'il est nécessaire de charger des faits à partir de sources de données externes, par exemple d'une base de données, de fichiers, d'envoyer des demandes à des services externes, etc. Il sera pratique de représenter le concept sous la forme d'une fonction qui traduit la requête d'entrée en requête vers la base de données et renvoie le résultat de l'exécution de cette requête. Parfois, il est logique d'abandonner une conclusion logique, en la remplaçant par une implémentation spécifique qui prend en compte les spécificités d'un problème spécifique et le résout plus efficacement. Il est également plus pratique de décrire dans un style fonctionnel des séquences infinies qui génèrent des entités conceptuelles, par exemple, une séquence d'entiers.



Les principes de travail avec de tels concepts devraient être les mêmes qu'avec les autres concepts décrits ci-dessus. La recherche de solutions doit être lancée avec les mêmes méthodes. Ils peuvent eux-mêmes être utilisés comme concepts parents dans les définitions de concepts. Seule la mise en œuvre interne de la recherche d'une solution devrait différer. Par conséquent, nous allons introduire une autre façon de définir un concept à l'aide d'une fonction:

concept < > (
< >, ... 
)
by <  >
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

Pour définir un concept défini à l'aide d'une fonction, vous devez spécifier une liste de ses attributs et une fonction de génération d'objets. J'ai décidé de faire de la liste des attributs un élément obligatoire de la définition, car cela simplifiera l'utilisation d'un tel concept - pour comprendre sa structure, vous n'aurez pas à étudier la fonction de génération d'objets.



Parlons maintenant de la fonction de génération d'objets. De toute évidence, il devrait recevoir une demande en entrée - les valeurs initiales des attributs. Puisque ces valeurs peuvent être spécifiées ou non, pour plus de commodité, elles peuvent être placées dans un tableau associatif, qui sera l'argument d'entrée de la fonction. Il sera également utile de savoir dans quel mode la recherche des significations des concepts est lancée - trouver toutes les valeurs possibles, ne trouver que la première ou vérifier uniquement l'existence d'une solution. Par conséquent, nous ajoutons le mode de recherche comme deuxième argument d'entrée.



Le résultat de l'évaluation de la fonction doit être une liste d'objets conceptuels. Mais, étant donné que la procédure d'inférence basée sur la recherche avec retour arrière consommera ces valeurs une par une, il est possible de faire de l'argument de sortie de la fonction non pas la liste elle-même, mais un itérateur. Cela rendrait la définition du concept plus flexible, par exemple, cela permettrait, si nécessaire, de mettre en œuvre une évaluation paresseuse ou une séquence infinie d'objets. Vous pouvez utiliser un itérateur de n'importe quelle collection standard ou créer votre propre implémentation personnalisée. L'élément de collection doit être un tableau associatif avec les valeurs des attributs de concept. Les essences du concept seront créées automatiquement sur leur base.

L'utilisation d'un itérateur comme type de retour a ses inconvénients. C'est plus encombrant et moins convivial que de simplement renvoyer une liste de résultats. Trouver la meilleure option qui allie polyvalence, simplicité et convivialité est un défi pour l'avenir.



À titre d'exemple, considérons le concept qui décrit les intervalles de temps. Disons que nous voulons diviser la journée de travail en intervalles de 15 minutes. Nous pouvons le faire avec une fonction assez simple:

concept timeSlot15min (id, hour, minute) by function(query, mode) {
    var timeSlots = [];
    var curId = 1;
    for(var curHour = 8; curHour < 19; curHour += 1) {
        for(var curMinute = 0; curMinute < 60; curMinute += 15) {
            timeSlots.push({
                id: curId,
                hour: curHour,
                minute: curMinute;
            });
            curId++;
        }
    }
    return timeSlots.iterator();
}
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

La fonction renvoie un itérateur pour toutes les valeurs possibles d'un intervalle de temps de 15 minutes pour une journée de travail. Il peut être utilisé, par exemple, pour rechercher des emplacements gratuits qui n'ont pas encore été réservés:

concept freeTimeSlot is timeSlot15min s where not exists (bookedSlot b where b.id = s.id)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

La fonction ne vérifie pas le résultat des calculs pour la conformité avec la requête de requête , cela sera fait automatiquement lors de la conversion d'un tableau d'attributs en une entité. Mais si nécessaire, des champs de requête peuvent être utilisés pour optimiser la fonction. Par exemple, formez une requête de base de données basée sur les champs de requête d'un concept.



Un concept à travers une fonction combine sémantique logique et fonctionnelle. Si dans le paradigme fonctionnel la fonction calcule le résultat pour les valeurs données des arguments d'entrée, alors dans le paradigme logique, il n'y a pas de division en arguments de sortie et d'entrée. Seule une partie des arguments peut être donnée, et dans n'importe quelle combinaison, et la fonction a besoin de trouver les valeurs des arguments restants. En pratique, il n'est pas toujours possible d'implémenter une telle fonction capable d'effectuer des calculs dans n'importe quelle direction, il est donc logique de limiter les combinaisons possibles d'arguments libres. Par exemple, déclarez que certains arguments doivent être liés à des valeurs avant d'évaluer une fonction. Pour ce faire, marquez ces attributs dans la définition du concept avec le mot-clé requis .



À titre d'exemple, considérons le concept qui définit les valeurs d'une certaine échelle exponentielle.

concept expScale (value, position, required limit) by function(query, mode) {
return {
    _curPos = 0,
    _curValue = 1,
    next: function() {
        if(!this.hasNext()) {
            return null;
        }
        var curItem = {value: this._curValue, position: this._curPosition, limit:  query.limit};
        this._curPos += 1;
        this._curValue = this._curValue * Math.E;
        return curItem;
    },
    hasNext: function() {
        return query.limit == 0 || this._curPos < query.limit; 
    }
}}
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

La fonction renvoie un itérateur qui génère des entités de concept à l'aide d'une évaluation différée. La taille de la séquence est limitée par la valeur de l'attribut limit , mais si elle est nulle, elle devient infinie. Les concepts basés sur des séquences infinies doivent être utilisés très soigneusement, car ils ne garantissent pas que la routine d'inférence se terminera. L'attribut limit est de nature auxiliaire et est utilisé pour organiser les calculs. Nous ne pouvons pas le déduire des valeurs d'autres attributs, il doit être connu avant le début du calcul, il a donc été marqué comme obligatoire



Nous avons envisagé l'une des options pour ce à quoi pourrait ressembler un concept en tant que fonction. Mais les problèmes de sécurité et d'utilisation de ces concepts nécessitent des recherches plus détaillées à l'avenir.

Aplatissement des collections imbriquées

Certains dialectes SQL qui peuvent travailler avec des données sous forme d'objet prennent en charge une opération telle que UNNEST , qui convertit le contenu d'une collection en un format de table (ensemble de lignes) et ajoute la table résultante à la clause FROM . Il est généralement utilisé pour aplatir des objets avec des structures imbriquées, en d'autres termes, pour les aplatir ou les aplatir. Des exemples de tels langages sont BigQuery et SQL ++.



Disons que nous stockons les informations utilisateur en tant qu'objet JSON:

[ {
"id":1,
"alias":"Margarita",
"name":"MargaritaStoddard",
"nickname":"Mags",
"userSince":"2012-08-20T10:10:00",
"friendIds":[2,3,6,10],
"employment":[{
    "organizationName":"Codetechno",
    "start-date":"2006-08-06"
},
{
    "organizationName":"geomedia",
    "start-date":"2010-06-17",
    "end-date":"2010-01-26"
}],
"gender":"F"
},
{
"id":2,
"alias":"Isbel",
"name":"IsbelDull",
"nickname":"Izzy",
"userSince":"2011-01-22T10:10:00",
"friendIds":[1,4],
"employment":[{
    "organizationName":"Hexviafind",
    "startDate":"2010-04-27"
}]
}, 
…]
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

Les objets utilisateur stockent des collections imbriquées avec des listes d'amis et de lieux de travail. Il est possible d'extraire les informations jointes sur les lieux de travail de l'utilisateur en les collant avec les données sur l'utilisateur prises au niveau supérieur de l'objet à l'aide d'une requête SQL ++:

SELECT u.id AS userId, u.name AS userName, e.organizationName AS orgName
FROM Users u UNNEST u.employment e
WHERE u.id = 1;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

Le résultat sera:

[ {
"userId": 1,
"userName": "MargaritaStoddard",
"orgName": "Codetechno"
}, {
"userId": 1,
"userName": "MargaritaStoddard",
"orgName": "geomedia"
} ]
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

Cette opération est discutée plus en détail ici .



Contrairement à SQL, dans le composant de modélisation, les données incorporées doivent être converties non pas au format tabulaire, mais au format objet. Les concepts discutés ci-dessus nous y aideront - un concept défini à travers une fonction et un concept anonyme. Un concept à travers une fonction vous permettra de transformer une collection imbriquée en format objet, et un concept anonyme vous permettra d'intégrer sa définition dans la liste des concepts parents et d'accéder aux valeurs de leurs attributs contenant la collection imbriquée souhaitée.



Puisque la définition complète d'un concept à travers une fonction est trop lourde pour être utilisée comme un concept anonyme:

concept conceptName(attribute1, attribute2, ...) by function(query, mode) {...}
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

nous devons trouver un moyen de le raccourcir. Tout d'abord, vous pouvez supprimer le titre de la définition de fonction avec les paramètres de requête et de mode . Dans la position du concept parent, l'argument mode sera toujours "trouver toutes les valeurs de concept". L'argument de requête sera toujours vide, car les dépendances sur les attributs d'autres concepts peuvent être incorporées dans le corps de la fonction. Le mot-clé concept peut également être supprimé. Ainsi, on obtient:

conceptName(attribute1, attribute2, ...) {…}
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

Si le nom du concept n'est pas important, il peut être omis et il sera généré automatiquement:

(attribute1, attribute2, ...) {…}
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

Si à l'avenir, il est possible de créer un compilateur capable de déduire une liste d'attributs à partir du type d'objets retournés par une fonction, alors la liste d'attributs peut être supprimée:

{…}
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

Ainsi, un exemple avec les utilisateurs et leurs lieux de travail en tant que concept ressemblerait à ceci:

concept userEmployments (
    userId = u.id,
    userName = u.name,
    orgName = e.orgName
) from users u, {u.employment.map((item) => {orgName: item.organizationName}).iterator()} e
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

La solution s'est avérée un peu verbeuse, mais universelle. Dans le même temps, si aucune transformation des objets de la collection imbriquée n'est requise, elle peut être considérablement simplifiée:

concept userEmployments (
    userId = u.id,
    userName = u.name,
    orgName = e. organizationName
) from users u, {u.employment.iterator()} e
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

résultats

Cet article s'est concentré sur deux questions. Tout d'abord, le transfert de certaines fonctionnalités du langage SQL vers le composant de modélisation: requêtes imbriquées, jointures externes, agrégations et jointures avec des collections imbriquées. Deuxièmement, l'introduction de deux nouvelles constructions dans le composant de modélisation: des définitions anonymes de concepts et des concepts définis à travers une fonction.



Un concept anonyme est une forme abrégée d'une définition de concept, destinée à être utilisée comme arguments pour des fonctions ( find , findOne et existe ) ou comme définition de concept imbriqué dans une clause where... Il peut être considéré comme analogue aux définitions de fonction anonymes dans les langages de programmation fonctionnelle.



Un concept défini à travers une fonction est un concept dont la manière de générer des objets est exprimée à l'aide d'un algorithme sous une forme explicite. C'est une sorte d '"interface" entre les mondes de la programmation fonctionnelle ou orientée objet et de la programmation logique. Elle sera utile dans de nombreux cas lorsqu'une manière logique de définir un concept n'est pas pratique ou impossible: par exemple, pour charger les faits initiaux à partir de leurs bases de données, fichiers ou des requêtes vers des services distants, pour remplacer la recherche logique universelle par ses propres mise en œuvre optimisée, ou pour implémenter des règles arbitraires créant des objets.



Il est intéressant de noter que les emprunts à SQL, tels que les requêtes imbriquées, les jointures externes et les jointures de collection imbriquées, n'ont pas nécessité de changements majeurs dans la logique du composant de modélisation et ont été implémentés à l'aide de concepts tels que des concepts anonymes et des concepts via une fonction. Cela suggère que ces types de concepts sont des outils flexibles et polyvalents avec une grande puissance expressive. Je pense qu'il existe de nombreuses façons plus intéressantes de les utiliser.



Ainsi, dans cet article et dans deux articles précédents, j'ai décrit les concepts de base et les éléments du composant de modélisation d'un langage de programmation hybride. Mais, avant de passer aux problématiques d'intégration d'un composant de modélisation avec un composant de calcul qui implémente un style de programmation fonctionnel ou orienté objet, j'ai décidé de consacrer l'article suivant à ses options possibles pour son application. De mon point de vue, le composant de modélisation présente des avantages par rapport aux langages de requête traditionnels, principalement SQL, et peut être utilisé seul sans intégration profonde avec le composant de calcul, que je souhaite démontrer avec plusieurs exemples dans le prochain article.



Le texte scientifique complet en anglais est disponible à l' adresse : papers.ssrn.com/sol3/papers.cfm?abstract_id=3555711



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 Nous

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