Le blog de SpiceGuid

Profil Contributions

Après avoir présenté le modèle Entités-Relations, on présente deux opérations élémentaires sur ces diagrammes ainsi qu'un programme BDD (Base De Données) qui implante ces deux opérations.

Le programme éric

Eric (Entity-Relationship Interactive Calculator) est le petit frère de Georges.

Il est précompilé pour MS-Windows et Linux x86.

 La source est écrite en OCaml.

La jointure

C'est le mécanisme de base d'ajout dans la base de données.

Au lancement du programme la base est totalement vide.

La commande join permet d'ajouter des diagrammes dans la base.

join ([Cat] On [Mat]).

La BDD est irredondante, tout nouveau diagramme est jointuré avec les concepts et les relations nouvelles ou existantes.

Par exemple les deux commandes suivantes :

join ([Woman Sarah] SpouseOf [Man John]).
join ([Woman Sarah] ColleagueOf [Man John]).

Sont équivalentes à cette unique commande :

join ([Woman Sarah*w] SpouseOf [Man John*m]) (w ColleagueOf m).

Car les concepts de départ et d'arrivée des relations sont les mêmes.

La jointure s'effectue également sur les relations, il ne peut pas y avoir deux relations de même nom reliant les deux même concepts de départ aux deux même concepts d'arrivée.

La sélection

C'est le mécanisme de base de la requête dans la base de données.

Seuls les concepts peuvent être variables, on reconnaît une variable-concept à ce qu'elle a un marqueur mais pas d'étiquette. La recherche tente d'associer une étiquette-concept à chaque variable-concept de sorte que le (ou les) graphe résultant soit dans la base de données. Les relations ne sont jamais des variables, ce sont toujours des constantes.

join ([Liquid Water] Boil [Celsius +100]).
join ([Liquid Azote] Boil [Celsius -196]).

select ([*liquid] Boil [*temp]).

Renvoie toutes les températures d’ébullition connues.

select ([*w] ColleagueOf [*m])(w SpouseOf m).

Renvoie toutes les personnes w et m qui sont à la fois collègues et époux.

select
  ([Believe *b] Experiencer [*t])
  (b Theme [Proposition *p])
  (p Statement [Want *w])
  (w Experiencer [*e])
  (w Theme [Situation *s])
  (s Description [Marry *m])
  (m Agent e).

Renvoie toutes les personnes t qui pensent qu'une personne e veut se marier (on ne demande ni avec qui, ni où, ni quand).

Renvoie tous les verbes de la contine de la souris verte :

select
  ([*v0] Then [*v1])
  (v1 Then [*v2])
  (v2 Then [*v3])
  (v3 Then [*v4])
  (v4 Then [*v5])
  (v5 Then [*v6])
  (v6 Then [*v7])
  (v7 Then [*v8])
  (v8 Then [*v9]).

Où l'on voit que le temps de recherche reste raisonnable malgré l'abondance de concepts variables

Les graphes imprimés par la commande select ont exactement la même syntaxe que les graphes acceptés par la commande join. 

Sauvegarder

La commande save sauvegarde la base de donnée en cours dans le fichier BDD indiqué.

save "database.eric".

Le chemin d'accès doit toujours avoir le caractère / comme séparateur et ce même sous MS-Windows. Par exemple save "F:/Concept graphs/BDD.eric". est une commande valide tandis que save "F:\Concept graphs\BDD.eric". est une commande invalide.

Charger

La commande load efface la base de données en cours et charge le fichier BDD indiqué.

load "database.eric".

Les fichiers BDD sont portables de Windows 32bits vers Linux 32bits et vice-versa. Pour une portabilité 64bits il faudrait recompiler la source.

Quitter

La fonction la plus importante de tout programme

quit.

Le méta-modèle

Le méta-modèle entités/relations c'est le modèle exprimé dans son propre formalisme. Il est extrêmement compact.

join
  ([Definition *def] Of [EntityRelationGraph])
  ([Set V *setV] RequiredBy def)
  ([Set E *setE] RequiredBy def)
  (setV Of [Vertex *v])
  (setE Of [Edge *e])
  (e Origin v)(e Destination v)
  (v LabelledWith [Concept])
  (e LabelledWith [Relation]).

Accessoirement le méta-modèle est aussi un schéma de conception pour l'implantation de Eric.

Conclusion

On a présenté un langage aussi élémentaire que possible pour la modélisation des connaissances ainsi qu'une implantation simple et efficace de ce langage.

De nombreuses extensions et variantes sont possibles pour ajouter de l'expressivité et/ou du raisonnement (assisté ou automatisé) à notre modèle de base.

Un modèle simple avec une sémantique intuitive.

La représentation du langage naturel

d'un côté le mode de communication le plus spontané pour l'humain est sa langue maternelle, comme le français ou l'anglais.

d'un autre côté le mode de fonctionnement de l'ordinateur exige une information symbolique hautement formalisée, ce formalisme est si exigeant qu'il constitue une barrière pour le non-spécialiste et un frein ou une perte de productivité pour le spécialiste.

indépendamment des problèmes d'interface homme/machine, formaliser un projet, une conception, un processus, et même tout type de création complexe, permet souvent de gagner de la clarté, de la cohérence et de la facilité de communication au sein d'une équipe.

Le modèle Entités/Relations tente de répondre à ces 3 problématiques en se voulant être un langage intermédiaire entre le langage parlé ou écrit et le codage pour une machine. Une modélisation entités/relations est une sorte de schéma pré-conceptuel. Il est suffisamment proche du langage écrit pour rester lisible par un humain tout en restant suffisamment structuré pour autoriser le traitement et la validation automatique par une machine.

Les graphes dirigés

Un graphe dirigé (ou digraphe en abrégé) est un diagramme qui comprend :

un ensemble de points (aussi appelés sommets).

un ensemble d'arcs (aussi appelés arêtes) orientés, chacune de ces arêtes orientées relie un sommet de départ à un sommet d'arrivé.

Il n'y pas d'autre contrainte particulière sur les sommets ou les arêtes. En particulier on autorise à ce qu'une (ou plusieurs) suite(s) d'arêtes forme(nt) un chemin cyclique.

Un digraphe étiqueté est un digraphe dont chaque sommet et/ou arête est annoté(e) par une certaine information. Par exemple si chaque sommet est étiqueté par le nom d'une ville alors chaque arête peut être étiquetée par la longueur (ou bien la durée) du trajet reliant une ville d'origine à une ville de destination.

Le modèle Entités/Relations

Le modèle Entités/Relations consiste à représenter l'information à l'aide d'un digraphe étiqueté où :

chaque sommet est étiqueté par une entité (on dit aussi un concept).

chaque arête est étiquetée par une relation (on dit aussi une association).

Avantage: un diagramme entités/relations étant un digraphe, tout résultat algorithme connu pour les digraphes est immédiatement transposable aux diagrammes entités/relations. Or les digraphes font parti des structures étudiées depuis longtemps en informatique, on possède tout un corpus de connaissances à leur sujet. Des connaissances qu'on pourra réutiliser pour étudier les (bonnes ou mauvaises) propriétés du modèle Entités/Relations.

Domaine: dans ce tutoriel on appliquera le modèle au traitement du langage naturel et à la représentation des connaissances. Le modèle peut toutefois s'adapter ou s'étendre pour couvrir à peu près n'importe quel domaine quelque part à la frontière du tout intuitif et du tout formel. 

Inconvénient: comme il s'agit plus d'un modèle pré-conceptuel que d'un modèle entièrement formel on sera amené à décrire nos représentations dans plusieurs langages, qu'ils soient naturels ou non. Français/anglais pour les langages naturels. Forme graphique ou textuelle pour les schémas associés. Enfin, pour les lecteurs plus avertis, on utilisera aussi la logique du premier ordre ( First Order Logic ou FOL en abrégé) pour la sémantique formelle ainsi que le langage de programmation OCaml pour l'implantation.
On n'hésitera pas à multiplier les exemples afin que chacun comprenne bien la démarche quelque soit son niveau de connaissance. On insistera particulièrement sur le passage du langage naturel au schéma entités/relations dans sa forme graphique et dans sa forme textuelle.

La forme graphique est la représentation en 2D tandis que la forme textuelle est la représentation linéaire ou 1D.

Les concepts

Textuellement un concept prend l'une des 5 formes suivantes :

[Home]
[Liquid: Water]
[VIP: #1]
[Celsius: +100]
[URL: "http://www.aeriesguard.com"]

Un concept est toujours encadré par un crochet ouvrant et un crochet fermant.

Le caractère deux-points est toujours facultatif.

Graphiquement un concept est encadré par une boîte rectangulaire.

Les relations

Une relation est simplement un nom reliant un concept d'origine à un concept de destination.

Textuellement une relation est toujours encadrée par une parenthèse ouvrante et une parenthèse fermante.

Graphiquement une relation est encadrée par une boîte arrondie à gauche et à droite.

Textuellement, un schéma entités/relations est une phrase qui se termine par un point.

Toute relation est binaire: elle relie un seul concept à un seul autre concept. C'est dû au fait qu'une relation est également une arête du digraphe sous-jacent.

A cat is on a mat.

En français: il y a un chat sur un tapis.

([Cat] On [Mat]).

Water boils at 100°C.

En français: l'eau bout à 100°C.

([Liquid Water] Boil [Celsius +100]).

I wash me.

En français: je me lave (la personne qui me lave c'est moi).

([Person:I*me] Wash me).

l'étoile * est suivie d'un nom (un marqueur) qui sert, dans une relation, à désigner la boîte-concept où il a été déclaré.

Il s'agit d'un premier exemple de diagramme contenant un cycle.

John is going to Boston by bus.

En français: John part en bus jusqu'à Boston.

Une relation Agent indique un sujet actif.

([Go *x] Agent [Person:John])
  (x Destination [City:Boston])
  (x Instrument [Bus]).

Spoiler (Sélectionnez le texte dans le cadre pointillé pour le faire apparaître)

En FOL ce diagramme est équivalent à l'expression ∃x∃y Go(x) ⋀ Person(John) ⋀ City(Boston) ⋀ Bus(y) ⋀ Agent(x,John) ⋀ Destination(x,Boston) ⋀ Instrument(x,y)

Par la suite on ne donnera plus la sémantique en FOL. Ce qu'il faut retenir c'est que chaque diagramme entités/relations possède une sémantique formelle précise (dépourvue d’ambiguïté).

Spoiler (Sélectionnez le texte dans le cadre pointillé pour le faire apparaître)

Un lecteur averti a fait la remarque selon laquelle une autre représentation était possible dans laquelle le verbe Go serait une relation et non un concept.

Le diagramme de gauche est basé sur un digraphe où les arêtes sont étiquetées par les relations. Le diagramme de droite est basé sur un graphe biparti où les arêtes sont étiquetées par des entiers.

Textuellement le diagramme de droite s'écrirait ainsi :

(Go [Person:John] [Bus] [City:Boston]).

Un graphe biparti est un diagramme qui comprend :

un premier ensemble de sommets de type E.

un second ensemble de sommets de type R.

un ensemble d'arêtes, chacune de ces arêtes relie un sommet de type E à un sommet de type R.

Dans cet article, pour des raisons que nous ne discuterons pas, on a choisi :

de baser le modèle Entités/Relations sur les digraphes plutôt que sur les graphes biparti

d'accorder (graphiquement) une boîte arrondie à chaque relation même si conceptuellement elle ne restera toujours qu'une simple étiquette sur une arête

Smiling Mary and her brother play with a toy car.

En français: Marie est souriante, elle et son frère jouent avec une voiture.

([Girl:Mary*m] Face [Smile])
  (m SisterOf [Boy*b])
  (m PlayWith [ToyCar*c])
  (b PlayWith c).

Tom believes that Eva wants to marry a sailor.

En français: Tom pense qu'Éva voudrait épouser un marin.

([Believe *b] Experiencer [Person:Tom])
  (b Theme [Proposition *p])
  (p Statement [Want *w])
  (w Experiencer [Person:Eva*e])
  (w Theme [Situation *s])
  (s Description [Marry *m])
  (m Agent e)
  (m Theme [Sailor]).

Dans ce document on a largement reprit le vocabulaire de John F. Sowa :

Une relation Attribut indique une propriété durable.

Une relation Agent indique un sujet actif.

Une relation Patient indique un sujet passif.

Une relation Theme indique un complément d'objet.

Une relation Location indique un complément de lieu.

Une relation Experiencer indique un sujet dans un certain état.

Les boîtes Proposition/Statement et Situation/Description permettent d'exprimer un concept composite, c'est-à-dire un concept lui-même défini par un diagramme entités/relations. Ces boîtes introduisent la notion de diagramme imbriqué à peu de frais (puisque le diagramme ne reste qu'un simple digraphe étiqueté).

Le marin existe-t-il réellement ? Ou bien peut-il n'exister que dans l'imaginaire de Tom ?

Spoiler (Sélectionnez le texte dans le cadre pointillé pour le faire apparaître)

Comment s'y prendre si l'on voulait préciser que Tom ne connaît pas le marin et ne sait pas s'il existe mais qu'il le pense. Il faudrait sans doute pouvoir délimiter un cadre en dedans duquel tout est supposition et en dehors duquel tout est certitude. Ce serait une extension du modèle proposé ici. Le modèle de base est inapte à exprimer une telle subtilité.

Une souris verte qui courait dans l'herbe

Une souris verte
Qui courait dans l'herbe,
Je l'attrape par la queue,
Je la montre à ces messieurs,
Ces messieurs me disent :
Trempez-la dans l'huile,
Trempez-la dans l'eau,
Ça fera un escargot
Tout chaud.
Je la mets dans mon chapeau,
Elle me dit qu'il fait trop chaud.
Je la mets dans un tiroir,
Elle me dit qu'il fait trop noir.
Je la mets dans ma culotte,
Elle me fait trois petites crottes.

A green mouse
Was running in the grass,
I catch it by the tail,
I show it to these fellows.
These fellows tell me :
Dip it in the oil,
Dip it in water,
And that will make a snail.
A hot one.
I put it in my hat,
She says to me that it's too hot.
I put it in a drawer,
She says to me that it's too black.
I put it in my trousers,
And she does 3 poos.

À ce stade la réalisation du diagramme (avec MS-Paint ) devient tellement laborieuse que je m'épargne cet effort pour passer directement à la forme textuelle :

([Mouse*mouse] Attribut [Color:Green])
  ([Run*run] Agent mouse)
  (run Location [Grass]) 
  (run Then [Catch*catch])
  (catch Agent [Person:I*i])
  (catch Patient mouse)
  (catch Instrument [Tail*tail])
  (tail Of mouse)
  (catch Then [Show*show])
  (show Agent i)
  (show Experiencer [Fellow Citizen*fellows])
  (show Then [Tell*tell])
  (tell Agent fellows)
  (tell Experiencer i)
  (tell Theme [Proposition*prop])
  (prop Statement [Dip#1*dip1])
  (dip1 Agent i)
  (dip1 Patient mouse)
  (dip1 In [Liquid Oil])
  (dip1 Then [Dip#2*dip2])
  (dip2 Agent i)
  (dip2 Patient mouse)
  (dip2 In [Liquid Water])
  (dip2 Then [Make*make])
  (make Agent i)
  (make Theme [Snail*snail])
  (snail Attribut [Temperature Hot])
  (tell Then [Put#1*put1])
  (put1 Agent i)
  (put1 Patient mouse)
  (put1 In [Hat*hat])
  (i Possess hat)
  (put1 Then [Say#1*say1])
  (say1 Agent mouse)
  (say1 Experiencer i)
  (say1 Theme [Temperature*temp])
  (temp Attribut [Too High])
  (say1 Then [Put#2*put2])
  (put2 Agent i)
  (put2 Patient mouse)
  (put2 In [Drawer*drawer])
  (put2 Then [Say#2*say2])
  (say2 Agent mouse)
  (say2 Experiencer i)
  (say2 Theme [Light*light])
  (light Attribut [Too Low])
  (say2 Then [Put#3*put3])
  (put3 Agent i)
  (put3 Patient mouse)
  (put3 In [Trousers*trousers])
  (i Possess trousers)
  (put3 Then [Poo*poo])
  (poo Agent mouse)
  (poo Repeat [Times 3]).

Conclusion

On a présenté un langage de modélisation à la fois raisonnablement simple et en même temps raisonnablement expressif. Bien entendu des extensions sont possibles, notamment pour effectuer des requêtes avancées et des raisonnements simples comme par exemple des syllogismes.

La forme graphique en 2D peut paraître plus lisible que la forme textuelle.

Toutefois la forme textuelle est incontournable pour au moins deux raisons. D'une part la forme graphique devient de plus en plus difficile à écrire/dessiner à mesure que la connaissance devient compliquée. D'autre part, une fois éditée, la base de connaissance doit pouvoir être sauvegardée pour ne pas être perdue. Or, pour des raisons technologiques, cette sauvegarde ne peut se faire que linéairement, en 1D.

Le modèle Entités/Relations est-il une base solide sur laquelle on pourrait bâtir une ou des formes d'intelligence artificielle arbitrairement évoluées, ou au moins rivalisant avec l'intelligence humaine. La réponse est malheureusement négative. Bien au contraire, le modèle Entités/Relations est une base fragile, toute extension inconsidérément ajoutée pour augmenter l'expressivité du modèle possède un coût en terme de computabilité. En particulier l'ensemble minimum de toutes les extensions désirables pour obtenir un modèle aussi expressif que FOL (First Order Logic) abouti aux mêmes limitations déjà bien connues en FOL: de nombreuses questions deviennent semi-décidables ou carrément indécidables (comprenez: il n'existe aucune façon connue pour l'ordinateur d'aboutir à une réponse positive ou négative).

 Le prochain tutoriel abordera les opérations élémentaires sur les schémas entités/relations, c'est-à-dire la jointure et la requête

Pas forcément une phrase par jour mais forcément un jour par phrase.

Sauf indication contraire l'auteur est le posteur. Deviens toi aussi un free-posteur en postant ta propre phrase du jour.

La construction européenne est une grande entreprise de démolition.

Une page cachée de mon site orange, extraite de ma correspondance avec Zeami.

Un coeur pour t'aimer

Un coquillage pour rêver

Une rose pour te garder

Un mouchoir pour pleurer

Un triangle absolu est une pyramide de pavés numérotés par des entiers de telle sorte que chacun d'eux indique la différence entre ses deux pavés immédiatement inférieurs. Un même entier ne peut pas être utilisé plus d'une seule fois.

Voici quelques triangles absolus:

Le logiciel de recherche

Kheopful.exe est un logiciel de recherche de triangles absolus pour console Win32, lancez Kheopful puis:

• entrez le nombre d'étages
• entrez le nombre d'entiers omissibles
• entrez le chiffre de reprise de la recherche (1 pour débuter une recherche)

Quand Kheopful.exe trouve une solution il affiche la base de la pyramide.

Lorsque vous interrompez Kheopful.exe (en appuyant Ctrl+C) notez le chiffre affiché, il vous servira comme chiffre de reprise de la recherche.

Le jeu tel que créé le 6 septembre 2006 pour l'anniversaire de tante Zeami.

Zeami's Birthday est un graticiel pour Windows 98 ou supérieur.
 
 Dans un monde en ruines, Zeami tente de rassembler les morceaux de ce qui faisait sa vie passée.

Le gameplay est comparable à Sokoban avec pour différence la possibilité d'assembler des briques selon un certain schéma.

Commandes du jeu

• Touches direction: Déplacer Zeami
• F4: Fenêtre/Plein-écran
• F5: Sauvegarder
• F6: Charger
• M: Musique on/off
• R: Recommencer le niveau
• Esc: Quitter le jeu

Le jeu contient un répertoire "bonus" qui donne accès à :

• la musique du jeu
• certains sons du jeu
• des icônes qui pourront servir à illustrer votre compte utilisateur Windows XP
• le fichier gmd pour Game Maker 5

Un tout petit effort pour rationaliser la présentation de l'approche algébrique de la résolution des cubes.

Par quoi faut-il commencer ?

Commencez par acheter et résoudre le Pocket-Cube. Si vous ne savez pas comment vous le procurer alors utilisez Gabbasoft Cube. N'achetez pas le mini-pocket-cube, ses rotations sont trop mauvaises. Le tutoriel sur le Pocket-Cube vous donne une solution pratique tout en introduisant en douceur quelques notions théoriques. Si vous n'arrivez pas à le résoudre avec le tutoriel d'Aerie's Guard cherchez un autre tutoriel sur internet.

Ensuite, pour approfondir vos notions théoriques, reportez-vous au Guide universel pour Univers³.

Que faut-il acheter comme cubes ?

Commencez par des cubes faciles, bons pour débuter :

• Le Pocket-Cube

• Le Pyraminx

• Le Domino
• La Tour 2×2×3

Puis continuez par les grands classiques, à l'aide des formules pour tous les cubes de 2³ à 5³ :

• Le Rubik's Cube ou le Do It Yourself
• Le Megaminx
• Le Eastsheen cube 4³
• Le Eastsheen cube 5³

• Une variante intéressante du Eastsheen cube 4³ consiste à étiqueter les facettes de façon à ce que chacune d'elle doive retrouver exactement sa place initiale (sinon les flèches ne seront pas alignées). Cette variante est également jouable à l'aide de Gabbasoft Cube.

Enfin, si vous rencontrez une difficulté, n'hésitez pas à posez votre question dans la rubrique univers³.

Le pire avec les test de QI (Quotient Imbécile) c'est le non-sens absolu de certaines questions.

Un exemple manifeste

Un autre exemple

Parmi les lettres H, A, B, M, T quelle est l'intruse ?

Et vous, vous est-il arrivé de rencontrer des Questions Idiotes dans les test de Quotient Imbécile ?

Moins de casse-tête pour le site.

D'abord je n'achète plus de cubes. Ceux que j'ai déjà me semblent suffisants pour l'instant. Il en existe des myriades d'autres mais je les trouve bien moins attractifs, autant sur le plan esthétique que sur le plan intellectuel.

La rubrique Univers Cubique n'est pas ce qu'on peut appeler une réussite en matière de traffic.
Peut-être mon approche n'est-elle pas assez pragmatique. Ou peut-être mes cubes sont-ils trop exotiques.
Je remercie Ertaï qui n'a eu de cesse de m'encourager. Cependant je ne me fais pas d'illusion, ce qui compte pour un web-master c'est la fréquentation, et là elle n'est clairement pas au rendez-vous.

La rubrique a eu des à-côtés très positifs, comme :

• m'obliger à me familiariser à fond avec l'éditeur de texte riche
• motiver certaines nouveautés comme la balise Spoiler et m'apprendre à créer des images PNG avec de la transparence

Dans le même ordre d'idées j'ai également arrêté :

• la construction en legos, y compris la photographie de mes constructions déjà existantes, notamment sur le thème Moyen-Âge
• les jeux-vidéos, les jeux en général, y compris le côté algorithmique

 
Tout cela pourrait donner à penser que je me désinvesti du Refuge. Bien au contraire, j'ai un nouveau projet logiciel qui devrait être potentiellement porteur de plus de synergies avec les talents du site. J'en dirai davantage dès que j'aurai quelque chose de plus concret à présenter.

Le post-mortem du projet Moonscript.

Pour les nouveaux et pour ceux qui n'auraient pas suivi (on les comprend), le projet Moonscript est un projet personnel de type tabula rasa en matière de paradigme de programmation. L'idée de base était bien de rejeter en bloc tout ce qui existe en langages de programmation puis de tout refonder (reconstruire) à partir d'un seul outil puissant et bien fondé: la théorie des catégories bicartésiennes fermées. Il s'agissait d'un projet fou uniquement compréhensible pour quelques informathématiciens passionnés. La version actuelle Moonscript 0.6 est sans doute la dernière version du projet. 

Comment rendre compte de l'expérience de quelque chose d'une abstraction aussi stratosphérique ?

D'abord il faut le vivre, pour éprouver l'excitation d'être à l'aube de quelque chose d'entièrement nouveau, une telle sensation on ne peut la rencontrer plusieurs fois dans une vie. Je peux dire que je l'ai vécue une fois et que j'en suis heureux. Moonscript, comme son nom l'indique, était dans la Lune et n'avait pas les pieds sur Terre. À mon avis je devais le faire car la vie professionnelle n'offre pas d'opportunités aussi détachées des réalités.

Ce qui a bien marché c'est l'implantation des structures habituelles (entiers, tableaux indexés, listes, queues, ensembles, dictionnaires, tas et files de priorités). Grâce à l'élégance toute mathématique de la théorie sous-jacente au code, toutes ces structures sont modélisées avec une concision et une sûreté inégalées. À ce stade là je n'utilisais que les notions (assez) bien maîtrisées de catamorphisme et de paramorphisme.

Ce qui n'a pas du tout marché en revanche c'est l'ajout du TAD (Type Abstrait de Données) graphe.
J'avais déjà tout ce que je désirais dans ma librarie de TADs, il ne me manquait plus que les graphes. Je voulais absolument avoir les graphes et les algorithmes associés, car c'est typiquement ce qui n'est pas fourni par les autres langages, et donc ça devenait comme un plus-produit, une raison d'être et d'exister pour mon langage. J'anticipais que d'éventuels utilisateurs seraient avant tout atirés par un confort inégalé pour manipuler les graphes et les concepts associés (transposé, connexité, dualité, clique, isomorphisme,...).

Et c'est là qu'est réapparu le fantôme d'une scission fondamentale que je croyais avoir enterrée d'un seul grand coup de marteau-pilon. N'importe quelle introduction sur les graphes vous le dira, il n'y a que deux façons d'implémenter un graphe :

• soit à l'aide d'une liste d'adjacence
• soit à l'aide d'une matrice

J'ai choisi la liste d'adjacence dans le style de Martin Erwig.

Le problème: je n'obtiens pas un TAD graphe mais seulement l'implémentation de ce TAD. Moonscript ne fait pas la distinction classique entre interface et implémentation. Cette distinction interface / implémentation est une idiosyncrasie de la programmation modulaire et de la programmation par objets, or Moonscript n'est ni un langage modulaire ni un langage de programmation par objets. Du coup j'ai une implantation mais je ne peux pas l'utiliser car aucune interface n'est disponible.

La solution: elle réside forcément dans la théorie des catégories bicartésiennes fermées. Puisque c'est mon seul et unique paradigme. Après mûre réflexion je suis arrivé à me convaincre que les métamorphismes offrent le type de transformation que je recherche. Ils font la conversion interface-implantation et vice-versa. Malheureusement j'ai beau googliser je ne trouve qu'une seule publication sur les métamorphismes. Assez pour me convaincre que je suis sur la bonne voie mais trop peu pour que je m'y engage. Une seule publication cela veut dire que la notion est sans doute encore très récente, pas assez étudiée, en tout cas pas assez pour être implantée dans un langage de programmation. Avant de lire cet article je ne savais même pas ce qu'est un métamorphisme. Autant dire que je dois abandonner. Pourtant je ne suis pas si loin du but. Dommage. J'y reviendrai peut-être un jour.

Pour ceux qui s'en souviennent je m'étais vanté d'une promesse de suivi/commentaires par un logicien reconnu. Il n'en a rien été. Aucun contact en 1 année.