Sémantique des résultats et mappings de types

Statut documentaire : reference — voir Maturité et preuves.

Un client H-Logic correct doit comprendre à la fois la cardinalité des requêtes et les mappings de types hérités. Ne pas supposer que toute requête retourne une collection, ni qu’un sous-type possède le même ordre visible de rôles que son parent.

Cardinalité des résultats

Le contrat de résultat est polymorphe :

• zéro réponse -> nil ;
• une réponse -> la valeur directement ;
• plusieurs réponses -> une liste conceptuelle chaînée.

Si l’expression return construit déjà un tuple ou une liste, le Runtime conserve cette forme au lieu de l’envelopper dans un conteneur singleton supplémentaire.

ask .:#Person(p)[name='Ada'] return p;
ask .:#Person(p) return p;
ask .:#Person(p)[name=name] return (p, name);

Les bindings hôtes doivent normaliser ce contrat explicitement plutôt que de déduire la forme à partir d’un seul cas de test.

Instances héritées

Un sous-type peut réordonner, projeter ou identifier des rôles de son supertype. Une requête via un ancêtre peut donc retourner une vue conceptuelle mappée qui préserve l’identité de l’instance descendante réelle tout en présentant les rôles dans l’ordre apparent du type demandé.

define .:#Parent(left:#Value, right:#Value);
define .:#Child(first:#Value, second:#Value);
#Child ->_[map=#[[0,1],[1,0]]] #Parent;

Polyadic maps

Un polyadic map n’est pas une simple permutation. Sa forme normale peut représenter projection, positions répétées et composantes d’égalité. La forme polyadique normale est la source de vérité sémantique ; tout cache positionnel n’est qu’une optimisation dérivée lorsque la correspondance est unique.

Règle côté client

Lors de la projection de résultats H-Logic vers .NET ou un autre binding, préserver l’identité conceptuelle et utiliser le mapping apparent fourni par le Runtime. Ne jamais reconstruire une vue parent en supposant les positions brutes.