Résumé ou Approche simplifiée des identificateurs, contextes et modules

3.6.1. Identificateurs

Les identificateurs sont des objets Prolog qui peuvent servir à la construction d'autres objets Prolog. On distingue deux modes d'utilisation des identificateurs :

Dans tous les cas, la syntaxe d'un identificateur Prolog (§3.3.) est : prefixe:suffixe

prefixe et suffixe sont des suites de caractères en accord avec la syntaxe choisie (Prolog II ou Edinburgh), : peut être remplacé par un caractère graphique (cf. set_prefix_limit).

Cette syntaxe a l'avantage de pouvoir désigner un gros ensemble d'identificateurs simplement d'après une particularité de leur nom.

On appellera famille d'identificateurs de préfixe "untel", tous les identificateurs (prédicats ou foncteurs) dont le nom s'écrit untel:suffixe (§3.2.).

On appellera module de préfixe "untel", ou par extension module "untel", toutes les règles et/ou tableaux et/ou variables statiques dont l'identificateur d'accès s'écrit untel:suffixe (§3.2.).

Astuce : si vous voulez un identificateur invariant pour tous les programmes, simple à écrire et facile à retenir, choisissez pour cet identificateur le préfixe vide. Il est appelé dans les paragraphes précédents (§3.1.2.): foncteur générique.

3.6.2. Notation abrégée et contextes

On rencontre très fréquemment des situations où la grande majorité des identificateurs que l'on doit traiter, s'écrit toujours avec le même préfixe. On voudrait donc se passer de répéter ce préfixe et avoir une représentation d'identificateur sous forme abrégée.

Dans cette optique, pour simplifier la mise en œuvre et la lisibilité des programmes, il existe des conventions pour une représentation simplifiée des identificateurs, qui déterminent de manière unique la donnée Prolog. Ces conventions sont appelées contextes de lecture/écriture (§3.4.).

La conversion entre le codage interne de la donnée et sa représentation externe est réalisée uniquement au cours des opérations de lecture et d'écriture.

Un contexte de lecture/écriture permet de dire :

sauf contre ordre, toutes les représentations d'identificateurs abrégées lues doivent prendre le préfixe par défaut pref, exceptées les représentations abrégées suivantes id1, id2, id3, … qui prennent respectivement les préfixes pref1, pref2, pref3, … . Et pour tout ce qui doit être écrit, c'est à dire lorsque l'on doit construire la représentation la plus concise possible, faire en sorte qu'après relecture, on obtienne l'identificateur Prolog qu'on voulait écrire.

Un contexte désigne donc quel préfixe doit être attribué à la représentation simplifiée d'un identificateur pour obtenir sa représentation complète. D'où la définition du contexte par :

Propriétés:

• La liste des attributions explicites est traitée de gauche à droite.

• Si une représentation abrégée apparaît plusieurs fois dans la liste on lui attribuera le premier préfixe associé (c'est à dire le plus à gauche).

• Toutes les chaînes déclarées dans le contexte n'ont pas besoin de correspondre à des identificateurs existants. Si Prolog doit créer ou lire un identificateur, il consultera cette liste de représentations potentielles.

Pour abréger d'avantage l'écriture (même dans la définition du contexte), si on veut faire apparaître dans la liste explicite toute une famille d'identificateurs, au lieu de la mentionner de manière exhaustive, il suffit simplement de spécifier son nom. C'est alors considéré comme une attribution implicite, équivalant à calculer la liste explicite qui en découle et l'insérer dans la liste existante, au moment de chaque opération d'attribution de préfixe.

Propriétés:

• La liste des attributions implicites est traitée après la liste explicite. • La liste des attributions implicites est traitée de gauche à droite. D'où la définition du contexte par :

- une liste d'attributions explicites de préfixes, - une liste d'attributions implicites de préfixes, - un préfixe par défaut pour les autres cas. Et sa définition en Prolog (§3.4.4. et §3.4.5.):

set_context(Id, ListeExplicite, ListeImplicite, Defaut);

Ce contexte devient alors dépendant du temps, dans la mesure où les familles désignées pour une attribution implicite peuvent grandir avec le temps.

Pour se ramener à un contexte sain, et supprimer cette partie inconnue dans le cas d'attributions implicites, il est nécessaire de 'fermer' la famille. Cela signifie : au moment de la fermeture de la famille, la liste explicite qu'elle représente est calculée et mémorisée une fois pour toute. Le contexte est à nouveau complètement défini et invariant dans le temps.

3.6.3. Modules

Prolog étant incrémental, sans type de données, il n'y a aucune contrainte sur l'ordre d'insertion des règles.

Vous pouvez toutefois grouper toutes les règles d'un même module et les définir en même temps. Vous pouvez également définir des conventions de lecture de ce groupe de règles différentes de celles du contexte d'exécution. Ceci permet de rendre la définition du module autonome si le contexte est sain.

La définition d'un module peut donc se faire par l'énoncé de: - un contexte de lecture/écriture du module,

- éventuellement une règle d'initialisation du module, à exécuter juste après compilation ou chargement des règles.

La définition d'un module peut se faire en mode insertion, en utilisant la déclaration module ou omodule (§3.5.2):

insert; insert;

module(p,e,i,d); équivaut à ->set_context(p,e,i,d); ->mode_verif_prefixe(p); regles… regles… end_module(p); ->exec(p:ini_module); ->restaure_context; … … ; ;

Attention : si vous utilisez dans le contexte d'un module, des conventions implicites, même pour un contexte sain, il faut que la famille soit déjà définie pour que les attributions implicites se fassent. Dans la même optique, si vous faites appel, dans la règle d'initialisation d'un module, à des règles externes au module, il faut que ces règles soient déjà définies pour que l'initialisation se termine.

Cela signifie que, bien qu'il n'y ait pas de contraintes sur l'ordre des paquets de règles, il peut y avoir des contraintes sur l'ordre de compilation ou de chargement des modules.

Il est également important de noter que les notions de fichier et de module sont complètement indépendantes. Un même fichier source peut contenir plusieurs modules, et un même nom de module peut apparaître dans plusieurs fichiers chargés dans la même session.