Conventions

Afin d'obtenir un environnement stable pour PLUSHIE, il faut décider de certaines conventions.
Elles sont nécessaires, mais non prescriptives : on peut librement en choisir d'autres.


1- Sens de l'instruction principale

La première décision concerne la chiralité initiale de l’instruction principale. Il y a le choix entre :

SOURCE → DESTINATION

et

DESTINATION ← SOURCE

Les fichiers de code texte sont actuellement écrits en utilisant :

DESTINATION ← SOURCE

Conséquences

  • Ce choix n'a pas d'importance, mais il faut écrire tous les fichiers de texte de code en cohérence et s'y tenir au moins le temps de définir un autre interpréteur.
  • Le tout début du fichier ini est un petit peu plus complexe à écrire en notation inversée SOURCE → DESTINATION ou bien il faut modifier le fichier de boot plusbase.mem
  • La notation DESTINATION ← SOURCE se rapproche plus d'une écriture d'affectation usuelle en informatique du type A = B
  • Ce choix ne peut pas facilement être inversé par du code PLUSHIE, il faut modifier l'interpréteur de base dans plusbase.mem
    Plus loin encore en poussant PLUSHIE plus loin, on pourrait disposer d'un interpréteur de chaque sens et d'une instruction PLUSHIE pour basculer le mode et avoir ainsi des portions de codes chirales l'une à l'autre.

☞ On notera que ce choix constitue la première rupture de symétrie du langage.

2- Affectation des rôles des cases mémoire

Le minimalisme a imposé de n'avoir que 2 adresses adressables par une adresse donnée, ce qui est le minimum pour construire des structures complexes.
Cellule mémoire élémentaire :
Tête
Suite


Elles sont appelées tête et suite, mais pourraient être appelées gauche et droite ou première et seconde. Les chaînes de caractères caractérisant les mots appris doivent être pointées soit par l'une, soit par l'autre. Une forme de chiralité apparaît entre : L'autre case de la cellule mémoire contient alors la valeur de la cellule.
☞ Ce choix constitue une deuxième rupture de symétrie du langage.
Complément

Toute autre convention est recevable pour nommer les deux adresses des cellules :
droite/gauche, première/seconde, etc. On peut même choisir qu'une adresse pointe vers plus de 2 adresses pour faciliter la gestion des hypergraphes.

Plus loin Là aussi, on peut gérer en parallèle deux types de chaînes au prix d'une gestion très pointue.


3- Ordre d'enregistrement des caractères lus

Avec l'interpréteur de base proposé ici, les caractères lus sont enregistrés dans une structure de pile, par insertion en tête de la chaîne d'entrée.
Il serait aussi possible de faire le choix d'une insertion en fin de la chaîne d'entrée.
Conséquences

  • Pour afficher à l'endroit une chaîne de caractère, il est nécessaire de l'inverser avant.
  • l'autre option demande un code de plusbase.mem un peu plus gros en petite contradiction avec l'objectif de minimalisme initial.
☞ ce choix constitue une troisième (mais faible) rupture de symétrie du langage.

4- Convention d'interprétation des bouclages

En PLUSHIE, il n'existe au départ aucun caractère spécial que ce soit un séparateur ou une valeur null, pas plus qu'un signal de fin de liste. Toute la structure repose sur la topologie.
Lorsqu'une liste est parcourue par un pointeur, cela peut se terminer en boucle infinie si l''un des éléments de la liste pointe vers un élément de la liste qui le précède (liste partiellement cyclique). À l'extrême, une cellule peut voir ses adresses en tête et/ou en suite pointer sur elle-même.

Il est naturel de choisir qu'une liste se termine quand la suite d'un élément pointe sur lui-même, et qu'une cascade se termine quand la tête d'un élément pointe sur lui-même (atome). Quatre bouclages d'une cellule mémoire sur elle-même sont possibles :

5- Convention de typographie des mots

Comme le montre cet exemple, PLUSHIE fonctionne très bien sans convention. C'est pour la lecture humaine, et pour éviter des erreurs de syntaxe trop faciles, qu'il est recommandé de s'assurer que l'interpréteur de PLUSHIE va découper les séquences de caractères aux endroits attendus.
Pour cela, il faut s'assurer que la fin d'une expression ne correspond pas à un mot connu. Le plus simple est de convenir de symboles de début et de symboles de fin.
De façon à ce que les instructions se rapprochent le plus possible du langage courant, la typographie suivante est recommandée : les expressions à découper commencent, si possible, par une majuscule et se terminent par un caractère espace. Cela ne fait pas de l'espace un séparateur au sens usuel. L'interpréteur de base de PLUSHIE n'a aucune notion de séparateur.
Plus loin D'autres conventions sont possibles et peuvent être mélangées indistinctement dans un code PLUSHIE. Mais il convient d'être rigoureux, les pseudo-bugs liés au découpage des phrases par l'interpréteur de base peuvent parfois se montrer retors dans ces cas de figure.

6- Convention de nommage des pointeurs

Rien n'oblige à identifier clairement par le nom qu'un mot pointe vers un autre.
Il est toutefois pratique pour le programmeur de choisir une convention pour désigner les pointeurs successifs et les reconnaître, surtout s'il s'agit d'intermédiaires de programmation.
Il existe de nombreuses possibilités. Le choix actuel s'est porté sur des symboles "<" placés à la fin du mot (mais avant l'espace de séparation si on préfère le conserver).
Exemple Ainsi "A<<< " désigne un pointeur de niveau 3 vers A, qui pointe donc en intermédiaire vers "A<< ", puis vers "A< " et enfin vers "A "
Notons que la convention inverse de prendre > placé avant le mot pointé ne fonctionne pas. En effet, dès que ">A " est un mot connu, ">>A " se fait découper en ">" et ">A " par l'interpréteur de base. Ensuite, une fois ">" isolé comme mot connu, tous les pointeurs notés en ">" se font découper.
Continuer vers technique