Pour l’ordinateur une variable a deux attributs: sa valeur (on peut y attacher une taille, un type…) et son adresse en mémoire. Pourquoi l’adresse en mémoire? Eh bien, c’est simplement l’information qu’il lui faut pour accéder à la variable quand elle est en mémoire vive.

Du coup, un programme tend à manipuler deux types de données. Il y a les variables qui représentent des valeurs comme des caractères ou des nombres, et les variables qui contiennent… l’adresse d’une autre variable. Nous appelons ces dernières des « pointeurs » ou des « références », des termes qui ne sont pas historiquement équivalents mais en pratique ils désignent le même objet.

Cette longue introduction a pour but de vous familiariser avec la notion de référence. Je voudrais maintenant passer au sujet principal: l’appartenance.

Le language Rust

Si vous suivez les fils d’information sur la programmation vous avez certainement, à un moment ou à un autre, entendu parler de Rust. En effet cette création de la fondation Mozilla a une profonde influence sur les derniers développements de systèmes d’exploitation et de certains logiciels, avec Microsoft et Linux qui s’y investissent.

La nouveauté de ce language est qu’il parvient à gérer la mémoire de façon sûre sans compromettre la performance. Et cela tient à son utilisation du concept d’appartenance pour les références.

Pour Rust, toute référence a une appartenance: une fonction ou un bout de code qui gère la variable pointée par la référence, comment et quand elle peut être modifiée ou désallouée. Le compilateur fait appel au fameux Borrow Checker (contrôleur d’appartenance) pour s’assurer que le code suit bien les règles définies par le language.

Je ne vais pas m’étendre ici sur ces règles, si ce n’est qu’elles inspirent directement la suite.

Références en dodo

Le language dodo a deux types de références, qui sont complètement différents (à la surface).

Il y a les références simples qui apparaissent dans les paramètres des méthodes comme dans cet exemple:

method Mixe(&Fruit[], Vitesse?)

La liste de fruits est passée par référence (marque &) pour pouvoir être modifiée à l’intérieur de la méthode. En effet connaître l’adresse d’une variable permet de la modifier de façon visible à l’extérieur. En contraste, la vitesse n’est pas une référence donc la méthode n’a accès qu’à sa valeur.

Mais c’est bien la limitation de ce type de référence: elle ne peut être utilisée que dans les paramètres d’une méthode ou d’un constructeur, pas dans les paramètres d’une fonction ou comme type d’un champ dans un objet.

Le deuxième type de référence est appelé Link (lien). Il s’apparente peut-être plus au pointeur traditionnel.

A la différence de la référence simple, Link peut être passé comme argument d’une fonction et stocké dans un objet. Cela le rend plus versatile mais aussi plus compliqué en terme de gestion sûre de la mémoire.

Gestion sûre de la mémoire avec Link

A sa création une variable Link pointe vers une adresse mémoire invalide (le fameux pointeur null que vous avez peut-être déjà rencontré). Il n’y a donc pas de variable à modifier ou désallouer à cette adresse. Son état à ce point est null (vide).

Quand on lui donne une valeur deux choses se passent:

• une variable est allouée en mémoire vive pour stocker la valeur
• la référence Link pointe vers cette variable et prend l’état owned (variable lui appartenant)

La variable appartient effectivement au code qui l’a créée en mémoire. Il n’y a pas d’autre code qui a accès à la variable.

A ce point la variable peut simplement être désallouée si le code s’arrête ici, ou recevoir une nouvelle valeur. Il n’y a pas vraiment de différence avec une variable ordinaire.

Elle peut aussi être passée à une autre fonction.

Il y a quatre façons de passer la variable à une autre fonction:

• de façon définitive: l’appartenance de la variable change, la fonction appelée en prend possession
• comme un lien passif, pour observation seulement
• temporaire, la variable peut être modifiée par l’appel mais l’appelant en retient l’appartenance
• finalement comme une référence simple si c’est une méthode ou un constructeur

Dans le premier cas l’appelant n’a plus rien à voir avec la variable et le lien reprend l’état null quand l’appel finit. Il n’y a pas de complication par rapport à l’utilisation de la mémoire puisque l’appelé en est responsable.

Dans le deuxième cas, l’état du lien passif reçu par la fonction est listener (variable suivie). L’appelé peut simplement consulter la variable sans la modifier.

La variable reprend son état initial quand l’appel finit.

Dans le troisième cas l’état du lien reçu par la fonction appelée est borrowed (variable prêtée). La fonction a la permission de modifier la variable. Elle peut aussi consulter la valeur de la variable ou la prêter à une autre fonction. Mais ça s’arrête ici.

En particulier, la fonction appelée ne peut pas désallouer la variable. Comme avant, la variable reprend son état initial quand l’appel finit.

method Remplace(&*Age)

Avec une référence simple le lien lui-même peut changer, alors qu’avec le prêt c’est juste la variable.

• Si le lien est actif, l’appartenance de la variable revient à l’appelant mais la variable originelle peut être désallouée par la méthode.
• Si le lien est passif le lien sortant doit avoir au moins la même durée de vie que le lien entrant (voir la prochaine section).

Référence Link comme attribut d’objet

Jusqu’ici nous n’avons vu que des références locales, ce qui signifie que la référence Link ne s’échappe pas du bloc d’instructions courant (fonction, méthode…)

A partir d’ici nous allons parler de références en état de partage (shared).

Si le lien est stocké comme un lien actif dans l’attribut d’un objet, cet objet devient le propriétaire de la variable (owned). Elle peut être consultée ou prêtée tant que l’objet est défini. Mais elle ne peut changer de propriétaire que quand l’objet est désalloué, donc en valeur de retour à la sortie de la fonction. Cela est similaire à une variable prêtée (borrowed).

Si le lien est stocké comme un lien passif dans l’attribut de l’objet le propriétaire de la variable ne change pas. Il faut donc prendre garde que la durée de vie de l’objet n’excède pas celle du propriétaire. La variable ne peut pas changer de propriétaire tant que l’objet est défini, car le nouveau propriétaire pourrait la désallouer alors qu’il y a toujours une référence. C’est une variable partagée.

Pour retourner un tel objet depuis une fonction il faut définir une exigence sur sa durée de vie à travers l’attribut lifetime de son type, comme dans l’exemple ci-dessous:

template (param: $A, retour: $S) [where A = Age(lifetime: $l) && S = Suivi(lifetime: $l)]
def suivi(Personne, A) → S

Cela indique que la durée de vie de l’objet retourné doit correspondre à la durée de vie du paramètre de type Age. Si l’âge passé en paramètre est stocké dans la valeur de retour de la fonction, le compilateur ne va pas produire d’erreur car il y a une garantie que l’âge sera défini pour toute la durée de vie de l’objet.

Une durée de vie peut avoir une valeur static. Cela indique qu’elle est de durée indéfinie et signifie que l’objet va occuper de la mémoire jusqu’à la fin du programme.

Le constructeur fait habituellement partie du baggage associé à la programmation orientée objet; cependant, ce n’est pas un composant essentiel de celle-ci. Il est tout à fait envisageable de faire de la programmation objet en se contentant de fonctions « fabrique » qui produisent des instances de classe en fonction de paramètres définis.

Ce qui distingue un constructeur de ces dernières, c’est que le constructeur agit sur une instance déjà allouée de la classe et peut (ou parfois, doit) déléguer partie de l’initialisation de l’objet à la superclasse.

Cette dernière propriété est la source de bien des soucis pour le programmeur orienté objet.

Prenons un exemple:

Dans cet exemple, le constructeur ne fait finalement rien. Mais une sous-classe peut avoir davantage d’attributs:

Dans B, le constructeur de A ne semble plus du tout anodin: puisque x n’est pas encore initialisé, il prend la valeur par défaut 0 quand le constructeur de A appelle F(), et la fonction au nom inquiétant LancerOgive() est invoquée!

Même si le développeur prend bien soin que self.x ne soit jamais 0 tant qu’il n’y a pas d’attaque en cours contre la sûreté nationale dans les méthodes de B, il est trop tard. Et le pire est qu’il n’a pas forcément de contrôle sur la classe A; l’appel à la méthode F() pourrait avoir été ajouté après que tous les tests du programme soient passés. C’est un problème général des langages orientés objet, dit « la superclasse fragile ».

Pour résoudre cela on pourrait interdire au constructeur de B d’appeler le constructeur de A sur self, mais il suffirait de remplacer cet appel avec celui de self.Init() pour retomber sur le même problème. En fin de compte, ce qui est important est que la variable x soit initialisée avant tout appel aux méthodes de A.

A noter qu’en dodo, il n’est pas toujours possible de provoquer ce problème. Les conditions qui le permettent sont:

• Le type A est polymorphique (venant de class)

Si ce n’était pas le cas, la fonction F() appelée dans Init() serait celle de A, puisque Init() n’aurait pas moyen de savoir que self est en réalité de type B et non A. Alors LancerOgive() ne serait pas invoquée.

• Le type B réutilise le prototype de A (def B)

Autrement, B ne pourrait pas invoquer la moindre méthode ou fonction de A sur self, puisque la structure des instances de B et de A n’ont potentiellement rien en commun. Cela est permis en dodo, et dans ce cas A est utilisé comme une interface que B implémente à sa façon.

• Le constructeur (ou une méthode) de A est invoqué avant que tous les attributs de B ne soient correctement initialisés.

Cela implique que ces attributs n’ont pas une valeur par défaut bien choisie.

J’ai mentionné le fait que dodo est un langage impératif par le biais des ses constructeurs. De fait, à l’intérieur d’un constructeur il est permis d’appeler d’autres constructeurs, appeler des méthodes avec effets de bord et aussi affecter de nouvelles valeurs aux attributs de l’objet, même si la classe n’est pas Mutable ou Editable (qui est une extension de Mutable).

Mais appeler des méthodes sur self, alors que les attributs de self peuvent encore changer, ne semble pas une bonne idée quand l’objet est sensé être constant. Les méthodes en question pourraient être déroutées quand les attributs de l’objet n’ont plus la valeur qu’ils prétendaient avoir. Pour cette raison dodo devrait imposer cette règle: affecter une nouvelle valeur aux attributs de l’objet n’est pas permis après que self a été passé à une méthode ou un autre constructeur dans le constructeur de la classe. Cela s’applique uniquement aux objets qui ne sont pas Mutable.

Pour que le danger de la superclasse fragile affecte une classe dodo, il faut donc que la superclasse soit Polymorphic, qu’elle soit modifiée sans préavis, que la classe affectée soit Mutable, réutilise le prototype de la superclasse, n’ait pas de valeur par défaut bien choisie pour ses attributs et fasse appel à des méthodes ou constructeurs de la superclasse avant d’être complètement initialisée.

Il n’est pas très difficile de réunir tous ces ingrédients mais il est encore plus facile d’éviter le danger.

Exemple d’enum en C:

Le type enum de dodo est différent. En fait, il correspond au type des identifiants tels que « plan »; la différence est qu’il n’y a pas de liste d’identifiants définie. Donc dodo permet de faire:

Heureusement il y a moyen de définir quels enums peuvent être affectés à une variable.

Cela se fait à l’aide d’une variable d’ensemble ou de table associative. Par exemple:

Dans cet exemple, style est un ensemble qui a quatre éléments. Un élément de cet ensemble est de type style.member, qui de par la déclaration est un enum… Mais dodo s’assure que l’élément est bien listé dans l’ensemble!

On peut donc déclarer une variable comme un enum appartenant à l’ensemble « style »:

C’est un concept puissant qui peut s’appliquer à d’autres types qu’enum, par exemple si l’on veut limiter la valeur d’une chaîne de caractères à un ensemble de chaînes bien défini.

Pour associer une valeur numérique à chaque identifiant, il faut utiliser une table associative plutôt qu’un ensemble:

Un enum qui appartient à deux ensembles peut être utilisé pour les deux. Mais un type d’enum n’est compatible que si l’ensemble est inclus dans l’autre. On pourrait faire:

Dodo associe une valeur interne à chaque enum qu’il rencontre pour pouvoir comparer les enums entre eux. Mais deux programmes dodo n’utilisent pas la même valeur interne pour le même enum. Par exemple, « plan » dans un programme peut être associé avec la même valeur que « creux » dans l’autre. Cela pose problème si ces programmes veulent échanger des données.

Pour pallier à cela, dodo demande que les enums échangés fassent toujours partie d’un ensemble (on peut utiliser style.member mais pas directement enum), et les deux programmes s’échangent la position d’un élément dans l’ensemble plutôt que sa valeur interne. De cette façon « plan » reste « plan » et ne se transfome pas en « creux » quand il est envoyé par message.

Nous y avons déjà touché dans l’article Le Modèle Objet de Dodo. En dodo, l’appartenance à un type implique que la variable dérive d’un prototype donné, et l’interface du type permet d’accéder ou manipuler la variable sur cette base.

Dans cet épisode nous allons nous intéresser particulièrement aux prototypes.

La façon la plus directe d’ajouter des fonctionnalités à une variable est d’étendre son prototype.

Par exemple:

Nous allons décomposer cela.

Cela commence une déclaration de variable. Tous les noms de type commencent avec une majuscule, ce qui n’est pas le cas de point donc il s’agit d’un nom de variable. Le mot def indique l’inférence de type (ou plutôt de prototype) locale, comme « auto » en C++11. On s’attend donc à une valeur d’initialisation.

Comme attendu, voici l’initialisation de la variable introduite par « = ». Le mot-clef new veut dire que l’expression étend un prototype, dans ce cas struct. Toute variable ou constante peut être utilisée comme prototype.

La variable struct est juste une structure vide, elle occupe zéro octet de mémoire et n’a aucun attribut membre. Je vais noter sa valeur {} à la façon de Javascript.

Vu la nature de struct, il n’y a pas vraiment d’utilité à l’utiliser comme prototype si l’on n’ajoute aucun membre. On s’attend donc à ce qu’un bloc de déclaration suive.

Voici le bloc de déclaration comme prévu. Celui-ci étend le prototype struct et par cela ajoute les attributs x et y en tant que membres de la variable point.

La variable double est utilisée comme prototype de x et y, qui prennent sa valeur (normalement 0.0) puisque ils n’ont pas de valeur d’initialisation. C’est l’équivalent de « def x = double; def y = double ». L’effet et la syntaxe sont les mêmes qu’une déclaration de variable en C++ avec une valeur par défaut.

Quand un prototype est étendu avec de nouveaux attributs membres, l’espace mémoire alloué est la somme de la taille du prototype et la taille des nouveaux attributs. Le prototype est copié au début de l’espace mémoire, suivi par les attributs.

Dans le cas de point la valeur d’initialisation est donc:

{ {}, 0.0, 0.0 }

Ceci occupe l’espace de deux double puisque struct n’occupe aucun espace mémoire.

Cette représentation en mémoire sert de guide à ce que l’on peut faire avec la variable point. Par exemple, on peut lui assigner une nouvelle valeur comme (2.0, -1.33) puisque c’est la notation de dodo pour une structure avec deux valeurs de (proto)type double, donc la représentation en mémoire est la même:

{ {}, 2.0, -1.33 }

Une propriété intéressante d’avoir le prototype en tête de la structure est qu’une variable ainsi structurée est compatible avec son prototype, et le prototype de son prototype, etc… Il suffit de se limiter aux premiers octets de la structure.

Par exemple, si l’on étend le prototype double avec de nouveaux attributs membres pour une variable, cette variable peut être utilisée partout où un double est attendu. Cependant les attributs supplémentaires peuvent être perdus dans l’opération.

Par exemple si l’on fait:

La variable struct_p n’a pas d’attributs x et y car son (proto)type est struct qui ne les a pas définis.

Ce qui est aussi intéressant de voir est quel est le type de retour d’un fonction retournant plusieurs valeurs. En programmation classique, une fonction ne retourne qu’une valeur:

Ici la valeur retournée par droite_1(point) est représentée en mémoire par:

{ {}, 1.0, 0.0 }

Mais dodo permet aussi de retourner plus d’une valeur. Cette notation révèle une autre caractéristique du langage dodo, le passage de continuations, qui n’a pas de limitation:

La représentation en mémoire de ce que retourne pos_droite_1(point) est:

{ 1.0, 0.0 }

D’après ce que l’on a vu auparavant, le premier élément de la structure est le prototype. Ici c’est un double, donc on peut assigner la valeur de retour à une variable de (proto)type double de par la compatibilité avec le prototype:

Mais dodo est aussi prêt à convertir la valeur de retour en struct étendue où toutes les valeurs retournées sont attributs membres, comme x et y dans point. On peut donc faire:

Où la représentation en mémoire de point1 est la même que pour droite_1(point):

{ {}, 1.0, 0.0 }

Il y a aussi des variables dont la représentation en mémoire dépend de l’état d’un ou plusieurs attributs membres. C’est le cas en particulier de class, le prototype des objets, qui a pour seul attribut une lien vers l’interface de l’objet:

{ Object }

L’interface de class est Object.

Toute classe d’objets qui étend ce prototype a un lien vers sa propre interface, ce qui permet à dodo de connaître sa représentation en mémoire.

Par exemple:

L’instance par défaut de cette classe, l’objet Figure.instance, est représenté en mémoire par:

{ Figure, { {}, 0.0, 0.0 } }

On peut définir la classe d’objets Cercle qui étend Figure:

Comme auparavant, le prototype est le premier membre de la structure pour Cercle.instance:

{ { Cercle, { {}, 0.0, 0.0 } }, 1.0 }

Mais si on assigne ceci à une variable de (proto)type Figure.instance, la valeur du lien (attribut dont dépend la représentation en mémoire) doit être changé en Figure:

Si ce n’était pas le cas la variable figure mentirait sur son état, ce qui cause des problèmes. Dodo utilise la relation entre Cercle et Figure pour déterminer la valeur à utiliser pour le lien. En fin de compte la variable est représentée par:

{ Figure, { {}, 0.0, 0.0 } }

Cela illustre bien que les prototypes ne se prêtent pas bien au polymorphisme. Si l’on veut préserver la nature de Cercle de l’objet, il faut utiliser le nom de la classe plutôt que son instance comme type:

Cette fois-ci, la représentation en mémoire de l’objet figure_cercle reste inchangée car il n’y a pas de contrainte sur la façon dont il est représenté:

{ { Cercle, { {}, 0.0, 0.0 } }, 1.0 }

Le problème des appels de fonction

Revenons au programme fzero que l’on avait traduit en C dans le volet précédent de cet article:

   int choix = 0;
   while (1) switch (choix)
   {
      case 0:
         if (n == 0) choix = 1;
         else choix = 2;
         break;
      case 1:
         return c_return;
      case 2:
         n = n - 1;
         choix = 0;
         break;
      default:
         c_throw->event.message = "Erreur de branchement!";
         return c_throw;
   }

Ce qui est notable c’est qu’il s’agit d’une fonction très simple. En particulier, cette fonction ne fait pas appel à d’autres fonctions dodo: le test if, les opérations n == 0 et n = n – 1 sont directement écrits en C ici.

Mais si elle contient un appel de fonction, d’après la logique du language dodo fzero devrait lui fournir une continuation à invoquer quand la fonction veut retourner à l’appelant.

Si l’on s’en tient à la convention d’une fonction C par fonction dodo, cela signifie que l’on devrait pouvoir sauter au milieu de la boucle while avec une branche (valeur de choix) différente de zéro.

Une solution

Une solution simple à cela serait de passer en tant que continuation non seulement la fonction à appeler, mais aussi la branche où il faut se rendre. Mais il peut y avoir d’autres données à inclure dans la continuation comme les paramètres de la fonction (n dans cet exemple). Si bien que la solution retenue utilise une structure C pour stocker l’adresse de la fonction, la branche et les autres données.

typedef void* (*continuation)(void*);

struct fzero_data
{
   continuation* function;
   int choice;
   int n;
   continuation** c_return;
   continuation** c_throw;
};

Ce qui est intéressant est que cela correspond à ce à quoi l’on s’attend pour une closure écrite en C. Il n’y a rien de bien étonnant à ça, comme j’avais dit auparavant il est facile de traduire les continuations de dodo en closures dans un language de programmation qui en dispose.

Exemple pratique

A ce point nous pouvons appeler une autre fonction dodo depuis la boucle while en spécifiant l’adresse de data comme continuation de retour. Par exemple, nous allons appeler une fonction qui écrit un texte à l’écran.

Nous pouvons donc utiliser la structure ci-dessus dans notre fonction:

continuation** fzero(int n, continuation** c_return, continuation** c_throw);

continuation** fzero_switch(struct fzero_data* data)
{
   int choix = data->choix;
   while (1) switch (choix)
   {
      case 0:
         if (data->n == 0) choix = 1;
         else choix = 2;
         break;
      case 1:
         return data->c_return;
      case 2:
         data->choix = 3;
         return printHello((continuation**) data, c_throw);
      case 3:
         data->n = data->n - 1;
         choix = 0;
         break;
      default:
         ((struct event_handler*) data->c_throw)->event.message =
            "Erreur de branchement!";
         return data->c_throw;
   }
}

La fonction fzero déclarée ci-dessus sera expliquée dans un prochain volet, mais nous pouvons déjà comprendre qu’elle crée une structure fzero_data avec les paramètres de la fonction puis appelle la fonction auxiliaire fzero_switch.

Le défi pour moi, l’architecte du langage, est de faire correspondre les concepts de dodo à une implémentation pratique offrant une performance acceptable. Je me suis donc tourné vers C avec l’idée d’écrire un convertisseur automatique de programmes dodo en C.

Seulement voilà, comment traduire?

La directive switch

Comme je l’ai suggéré dans la première partie, l’appel de continuation en dodo et la directive switch de C s’apparentent tous deux à GOTO, alors on peut écrire quelque chose comme:

   int choix = 0;
   while (1) switch (choix)
   {
      case 0:
         if (n == 0) choix = 1;
         else choix = 2;
         break;
      case 1:
         return c_return;
      case 2:
         n = n - 1;
         choix = 0;
         break;
      default:
         c_throw->event.message = "Erreur de branchement!";
         return c_throw;
   }

Cela correspond à une fonction dodo qui prend en paramètre un nombre n et le décrémente jusqu’à ce qu’il atteigne 0, puis retourne de la fonction:

   def fzero = fun(int n) => return(), throw(Exception):
      n = 0 ->
         return()
      |
         n - 1 -> n
         $fzero(n)
   .

La notation à continuations

Le code dodo ci-dessus ne ressemble pas vraiment à du C vous me direz. C’est que j’ai utilisé la notation à continuations pour bien illustrer la correspondance avec le switch. En réalité, le but est bien de pouvoir écrire la fonction fzero en style C comme ceci:

   def fzero(int n)
   {
      loop
      {
         case if (n = 0)
         {
            return()
         }
         .n = n - 1
      }
   }

À quoi bon transformer une fonction de style C en une fonction à passage de continuations, pour ensuite la transformer à nouveau en fonction C vous demandez-vous?

Hé bien pour le moment je compte implémenter juste la notation à continuations, de façon à avoir une base solide pour le langage, et ensuite m’attaquer à la transformation du style procédural en passage de continuations pour rendre le langage plus confortable à utiliser. Si un jour je trouve un langage avec continuations ou GOTO que je peux utiliser en lieu et place de C, il devrait être simple d’implémenter le langage de base de dodo avec lui. Le reste de dodo n’aura pas besoin d’être réécrit.

La boucle de continuations

Revenons à nos moutons.

Nous avons vu comment utiliser switch pour implémenter une fonction dodo simple qui se contente de décrémenter un compteur.

Pour ceux qui sont attentifs, il y a une continuation dans le switch qui n’existe pas dans la fonction dodo: celle du cas default. Un examen du code montre que ce cas n’est jamais atteint, mais il est bon de prévoir une erreur du convertisseur automatique (ou dans ce cas, du convertisseur humain puisque c’est écrit à la main!)

Si je parle du cas default c’est que ses instructions contiennent une ligne intéressante qu’il serait bon d’expliquer. C’est:

   c_throw->event.message = "Erreur de branchement!";

On y voit comment passer un paramètre à une continuation. En effet, c_throw est une continuation passée en paramètre à la fonction C. Il ne serait pas viable d’utiliser la technique du switch pour toutes les continuations du programme, dans une application conséquente il y aurait des centaines de milliers de cas dans le switch, sans compter qu’il faudrait trouver comment faire passer des arguments à une continuation sans mettre tout en variables globales.

Donc on garde la boucle de continuation décrite dans un article précédent pour interagir avec les autres fonctions.

Mais la boucle de continuation utilise des fonctions qui sont appelées en boucle, comment se fait-il que l’exemple utilise la notation c_throw->event qui suggère que c_throw est une structure pas une fonction?

C’est simple, c_throw est effectivement une structure. Mais son premier champ est un pointeur de fonction qui est utilisé par la boucle de continuations. Dans l’exemple donné, event est un autre champ de la structure. La boucle de continuations ne sait rien de event, ou des autres champs ajoutés à la structure.

Il faut que la fonction appelée par la boucle de continuations puisse lire une valeur fournie comme argument par l’appelant de la continuation qui, lui, connaît la structure de c_throw.

C’est pour cela que la boucle de continuation passe la structure en argument à la fonction. Dès lors, voici comment s’écrit la boucle de continuations:

   continuation suivante = premiere
   while (suivante != NULL)
   {
      suivante = suivante->appel(suivante);
   }

Gestion de la mémoire

Donc event est un champ de la structure passée en argument à la fonction C pour la continuation c_throw. Côté dodo il correspond à un argument de la continuation throw. Mais comment le programme alloue-t-il la mémoire pour les champs supplémentaires de la structure?

La boucle de continuations ne peut pas gérer cela, elle ne sait rien des champs supplémentaires et de plus elle ne saurait pas quand la mémoire n’est plus nécessaire et peut être libérée.

L’appelant pourrait utiliser malloc pour allouer la mémoire nécessaire. La mémoire pourrait être libérée au retour si elle n’est plus utilisée. C’était de fait ma première idée.

Un problème est que le contrôle ne retourne pas nécessairement à l’appelant quand la fonction termine. Un exemple courant est une fonction qui passe à une fonction appelée sa propre continuation return comme continuation de retour. Quand la fonction appelée fait return(), la fonction qui l’a appelée n’est pas informée.

Il faut donc intercepter cela pour libérer la mémoire allouée, avant que la continuation n’atteigne la boucle de continuations.

C’est alors qu’une autre idée m’est venue.

Plutôt que d’essayer de libérer la mémoire quand elle n’est plus utilisée, pourquoi n’essaierions-nous pas de préserver la mémoire qui sera encore utilisée jusqu’au retour de la fonction?

Pour cela, on dissocie la fonction dodo en deux fonctions C: l’une qui fait le travail et contient le switch, et l’autre qui préserve la mémoire utile jusqu’à la fin de la fonction et qui contient une boucle de continuations. La fonction au switch n’utilise la boucle de continuations que pour reprendre le contrôle quand une fonction appelée retourne ou pour terminer. La boucle de continuations continue tant que la continuation suivante appelle la fonction au switch (qui n’est donc pas terminée).

Il n’y a pas besoin d’utiliser malloc avec cette solution, la mémoire peut être préservée sur la pile.

Par exemple, si notre fonction fzero voulait afficher la valeur de n à chaque itération on pourrait écrire les deux fonctions:

   continuation fzero(int n, continuation c_return, continuation c_throw)
   {
      struct c_fzero donnees = {
         fzero_switch, // appel
         0,            // choix
         n,
         c_return,
         c_throw
      }
      continuation suivante = (continuation) &donnees;
      while (suivante->appel == fzero_switch)
      {
         suivante = suivante->appel(suivante);
      }
      return suivante;
   }

   continuation fzero_switch(continuation self)
   {
      struct c_fzero *donnees = (struct c_fzero*) self;
      int choix = donnees->choix;
      int n = donnees->n;
      while (1) switch (choix)
      {
         case 0:
            if (n == 0) choix = 1;
            else choix = 2;
            break;
         case 1:
            return donnees->c_return;
         case 2:
            donnees->choix = 3;
            donnees->n = n;
            return print_int(n, self, donnees->c_throw);
         case 3:
            n = n - 1;
            choix = 0;
            break;
         default:
            donnees->c_throw->event.message = "Erreur de branchement!";
            return donnees->c_throw;
      }
   }

On voit que si print_int retourne self, la boucle de continuation appelle à nouveau fzero_switch mais avec le choix 3. Par contre si elle retourne la continuation throw, la boucle de continuation de fzero termine.

Je conclus ainsi la seconde partie de Faire dodo en C.

Vous pouvez réagir dans les commentaires ci-dessous.

La table de hachage est une structure de données qui permet d’implémenter une table associative (que l’on appelle aussi un index ou un dictionnaire). Son principe est de répartir les données de façon homogène à l’aide d’une fonction de hachage appliquée aux clés de la table.

La plupart des langages de programmation offrent une table de hachage comme structure de données standard, avec peut-être l’exception notable du langage C (noter que le C++ comble cette lacune).

Mais est-il possible de faire mieux que la table de hachage proposée par défaut?

Mesure du mieux

Il y a différentes mesures qui déterminent la qualité d’une table de hachage.

L’une d’elle est le taux de remplissage – est-ce que la table accommode un certain nombre d’éléments sans laisser trop de « trous »?

Une autre est l’efficacité de consultation, et l’efficacité d’insertion. Je ne parlerai pas de l’efficacité d’enlever un élément.

Un facteur clé pour améliorer le taux de remplissage est une bonne fonction de hachage. Par exemple, si la fonction de hachage ne retourne jamais que des nombres entre 0 et 100, il est inévitable que plusieurs clés aient la même valeur de hachage après une centaine d’insertions. Même si la table de hachage se redimensionne pour accommoder plus d’éléments, ce sera en vain car tous les éléments vont se retrouver aux emplacements correspondants aux nombres de 0 à 100, en fait c’est contre-productif puisque le taux de remplissage se détériore!

La solution proposée dans cet article ne permet pas de compenser une mauvaise fonction de hachage. En fait elle est plus exigeante que les solutions traditionnelles car elle fait appel à plusieurs fonctions de hachage pour chaque clé.

Le principe de la seconde chance

Utiliser deux (ou davantage) fonctions de hachage est la base de la première astuce qui va nous permettre d’écrire une table de hachage super efficace, le principe de la seconde chance.

Etant donné une fonction de hachage h1 et une clé k, comment décider où placer l’élément dans la table de hachage? Une table de hachage fait généralement appel à un tableau de taille fixe (N) pour stocker les données, donc il s’agit de faire correspondre le numéro retourné par h1(k) avec un numéro d’index dans ce tableau.

Cela se fait souvent avec l’opération modulo, c’est-à-dire le reste de la division h1(k) / N. Le modulo donne un nombre entre 0 et N-1 qui est utilisée comme valeur d’index.

Si je rappelle tout cela, c’est pour mettre en exergue le fait qu’une tâche de la table de hachage est de gérer les collisions. En effet, il y a plusieurs valeurs telles que, par exemple, x modulo 100 est égal à 13. Si la valeur de hachage est 13, 113, 213, 313 etc il faut lui trouver une place même s’il y a déjà un élément à l’emplacement prévu.

Une solution est de rechercher un autre emplacement possible pour l’élément. Le principe de la seconde change utilise une différente fonction de hachage, disons h2, pour déterminer cet autre emplacement. Il est important que h1 et h2 soient indépendants, autrement il y a des chances que les deux fonctions retournent les mêmes deux résultats pour différentes clés.

Donc l’algorithme est:

p1 = h1(k) modulo N
si libre(p1)
  alors table[p1] = paire(k, élément)
sinon
  p2 = h2(k) modulo N
  si libre(p2)
    alors table[p2] = paire(k, élément)

Il est possible d’utiliser davantage de fonctions de hachage de la même façon que h2.

Pour retrouver un élément, on regarde aux différents emplacements possible pour voir s’ils contiennent la clé recherchée.

Si tous les emplacements sont déjà pris, il peut être nécessaire de redimensionner le tableau — ce qui donne un nouvel N et permet, on l’espère, de placer l’élément.

Il n’est pas très satisfaisant de devoir compter sur un N qui a exactement la bonne valeur pour pouvoir placer un élément, d’autant plus qu’il est coûteux de redimensionner la table de hachage car tous les éléments prennent un nouvel emplacement. L’efficacité de consultation est très bonne mais utilisé seul, le principe de seconde chance donne un taux de remplissage avoisinant les 50%.

Le principe du coucou

Pour améliorer cela, on utilise une autre astuce: le principe du coucou. Le bébé coucou, il est bien connu, est né dans le nid d’autres oiseaux et se fait de la place en jetant les oeufs du nid par-dessus bord. Pour une table de hachage, l’idée est de faire de la place en déplaçant l’élément existant autre part.

Certains utilisent les fonctions de hachage pour trouver un nouvel emplacement à l’élément existant dans la table de hachage. S’il n’y a pas d’emplacement libre, il peut y avoir des déplacements en cascade. Mais une étude a montré qu’un seul déplacement par insertion est nécessaire pour une bonne efficacité.

Ma solution, de son côté, utilise une réserve pour les éléments existants déplacés. Dans mes tests, en utilisant une table de hachage de 50 à 100 éléments comme réserve, le taux de remplissage excède facilement 90% pour l’insertion de 250 à 10000 éléments jusqu’à saturation.

C’est tout bonnement excellent pour une solution aussi simple et économe en espace mémoire.

L’algorithme combinant le principe de seconde chance avec deux fonctions de hachage, le principe du coucou et une réserve est:

p1 = h1(k) modulo N
si libre(p1)
  alors table[p1] = paire(k, élément)
sinon
  p2 = h2(k) modulo N
  si libre(p2)
    alors table[p2] = paire(k, élément)
  sinon
    p = choix(p1 ou p2)
    ajoute(réserve, table[p])
    table[p] = paire(k, élément)

Si la réserve est pleine on a le choix de redimensionner le tableau ou la réserve. Je pense que l’idéal est d’augmenter les deux jusqu’à ce que la taille de la réserve soit trop grande pour être stockée dans une ligne de cache ou une page de mémoire, puis n’augmenter que la taille du tableau. Mes tests montrent qu’il n’y a pas d’avantage à avoir une très grande réserve.

Pour la réserve on peut utiliser une table de hachage comme je l’ai fait ou on peut utiliser une liste ordonnée par valeur de hachage, dont l’ordre peut être maintenu de façon efficace pour un nombre d’éléments restreint (O(log N) pour la consultation et pour l’insertion). L’avantage est que la liste ordonnée peut accepter des éléments dont toutes les valeurs de hachage sont identiques.

Problème: je n’ai qu’une seule fonction de hachage!

Souvent en standard on n’a qu’une seule fonction de hachage à disposition, par exemple en Java il y a x.hashCode(). Dans le cas d’un objet composé de plusieurs attributs, on peut simplement prendre les attributs uniques à l’objet et utiliser leurs fonctions de hachage.

Il y a un autre moyen. Puisque l’index dans le tableau est calculé à l’aide de h1(k) modulo N, le résultat non fractionnaire de la division n’entre pas en compte. Par exemple si:

N = 100
h1(k)=1113

alors l’index est 13. On n’utilise pas les deux premiers chiffres 11.

Donc on peut utiliser la partie entière de la division h1(k) / N comme seconde valeur de hachage.

Et maintenant, à vos claviers!

La réalité n’est pas si simple.

Il y a une fondamentale différence entre la façon dont dodo structure le code et C structure le code. C est un langage procédural, l’unité d’organisation du code est la fonction. De son côté dodo se base sur les continuations.

Nous l’avons vu dans un article précédent, il est possible de simuler les continuations avec des fonctions à l’aide de la boucle de continuations.

Mais C y met un autre obstacle: il n’offre pas de closures. Le rôle des closures est de capturer les variables qui doivent être encore utilisées par la suite. Les fonctions de Clojure font office de closures, ce qui m’a permis d’écrire une première implémentation (dodo0). En C il faut mettre en place un autre mécanisme pour préserver les données qui doivent être réutilisées dans d’autres continuations.

Mon idée est de faire correspondre une fonction dodo à une fonction C. Puisque les variables d’une fonction sont généralement utilisées tout au long de son exécution, on peut les préserver au niveau d’une fonction.

Une continuation est l’équivalent d’un GOTO, et en C la directive switch est aussi équivalente à GOTO. Alors chaque fonction a une boucle avec un switch pour aller d’une continuation à l’autre.

Mais il faut aussi pouvoir appeler d’autres fonctions dodo, qui s’attendent à une continuation de retour. Pour cela chaque fonction C a une fonction auxiliaire qui se charge de sauter directement à la continuation désignée lors de son appel.

J’ai trouvé que dans certaines circonstances il était possible de faire tout cela sans allocation de mémoire, uniquement sur la pile! C’est une bonne nouvelle.

Dans un prochain épisode, je donnerai plus de détails et des exemples de code. A bientôt!

Une chaîne de caractères en dodo peut simplement s’écrire entre double guillemets.

   "Bonjour"

Par défaut, le programme utilise le même encodage de caractères que le fichier source. Le compilateur détermine l’encodage du fichier à sa lecture. Cependant la détection d’encodage de fichier n’est pas une science exacte et dépend souvent de la configuration du système. Le compilateur doit permettre de fournir le nom d’un encodage de caractères au moment de la compilation.

Pour choisir l’encodage des caractères d’une chaîne pour le programme il est possible de précéder les guillemets ouvrants avec un code. Par exemple, « x » est le code qui indique un encodage de caractères en UTF-16.
Le compilateur traduit de l’encodage du fichier en celui spécifié pour la chaîne de caractères.

Contenu

En fonction de l’encodage sélectionné, les caractères qui composent la chaîne peuvent occuper un octet ou plus. Par exemple en BIG5 les caractères chinois occupent deux octets et les caractères latins n’en occupent qu’un.
En Unicode il est même possible d’utiliser plusieurs caractères – ou codepoints – pour écrire une lettre, par exemple un accent aigu et « e » font un « é ».

Au vu de ces considérations, on ne peut pas toujours faire correspondre une position absolue dans la chaîne avec un caractère. Cela signifie que pour obtenir, par exemple, le cinquième caractère de la chaîne il faut soit partir du premier caractère et avancer caractère par caractère, ou il faut utiliser une représentation interne différente pour les caractères.

Dodo considère que le choix d’encodage du programmeur prend précédence, et n’impose pas sa propre représentation interne des chaînes de caractères.
En cela dodo est différent de Java et autres langages qui sont standardisés avec UTF-16 ou un autre encodage de caractères. Pour les opérations telles qu’obtenir le cinquième caractère, une chaîne de caractères peut être convertie en un tableau de caractères de façon efficace.

Caractères spéciaux

En dodo il n’y a pas de caractère d’échappement prédéfini. Donc les caractères spéciaux peuvent simplement être insérés dans la chaîne, sans les précéder d’un caractère d’échappement. Cela implique aussi qu’une chaîne de caractères ne peut pas contenir de double guillemet.

   "antislash: \, dollar: $, apostrophe: ', pourcent: %"

Pour exprimer le double guillemet, les caractères de contrôle et les caractères qui ne peuvent pas être représentés à l’aide de l’encodage de caractères courant, dodo a une syntaxe pour un seul caractère:

   \"
   \n
   \u2030

Un tel caractère peut être ajouté à une chaîne de caractères par concaténation. De plus, rien n’empêche les fonctions comme sprintf() d’interpréter certaines séquences de caractères comme des caractères échappés.

Texte multi-ligne

Dodo aide le programmeur à se rappeler de fermer une chaîne de caractères en rejetant une ligne qui a des guillemets ouvrants mais pas de guillemets fermants. A moins que la ligne suivante commence avec des guillemets.
Si la ligne suivante commence avec des guillemets alors la chaîne de caractères continue à la ligne suivante, et ainsi de suite jusqu’à une ligne qui contient des guillemets fermants.

   "ligne 1
   "ligne 2"

L’inconvénient est que cela fait un nombre impair de double-guillemets sur une ligne, ce qui ne plaît pas aux éditeurs de texte. Pour pallier à cela, on peut utiliser trois double-guillemets pour indiquer que la chaîne continue sur la ligne suivante.

   "ligne 1"""
   "ligne 2"

Cette syntaxe a aussi l’avantage de révéler s’il y a des espaces en fin de ligne.

Conclusion

En attribuant un encodage à chaque chaîne de caractères et en convertissant automatiquement de l’encodage système vers l’encodage spécifié, dodo permet un grand contrôle sur la représentation des chaînes de caractères dans le programme.

La gestion des chaînes de caractères dans dodo s’efforce d’apporter des réponses aux problèmes courants. Par exemple, les opérations sur les caractères et les opérations sur les codes sont clairement séparées.

Si certains choix de syntaxe peuvent porter à débat (notamment l’absence de caractère d’échappement) ils ont leurs avantages et ne sont pas difficiles à s’habituer.

A propos de la syntaxe, je vais refermer ce chapitre avec une proposition de syntaxe pour la concaténation de chaînes de caractères.
Si une expression est une chaîne de caractères entre double guillemets, elle peut être suivie d’une expression entre parenthèses et du reste de la chaîne de caractères. Il n’est pas nécessaire de spécifier l’encodage pour le reste de la chaîne.

   x"Utilisateur = "(\")(nom)(\")(\n)"Age = "(age)(\n)

Qu’en dites-vous?

struct Int32bits is Countable, is Indexed, is Iterable
{
   toInt => Integ32
}

def Integ32 = new Integer(size: 32)
{
   toBits => Int32bits
}

Integ32 n = 345
.n = n.toBits << 1   # assigne à n en convertissant avec toInt

Cependant, on peut vouloir interpréter la valeur comme une série d’octets au lieu de bits. Ou bien vouloir encore d’autres interprétations… La définition du type ne peut pas prévoir toutes les permutations.

De plus, la fonction de conversion peut être difficile à écrire en dodo.

Le langage C offre deux alternatives bien connues pour résoudre cela: la coercion de type et l’union. Ce sont deux mécanismes qui sont responsables pour grande partie du caractère dangereux de la programmation C, avec l’utilisation des pointeurs.

Il faut noter que Java a aussi la coercion de type (avec des limites) mais pas les pointeurs. Comme Java est généralement considéré sûr, on pourrait juste le copier.

Mais je n’aime pas me contenter de l’existant

Voici quelques idées de travail.

Comme je l’ai remarqué entre parenthèses plus haut, la coercion de type en Java est limitée. Il y a des coercions prédéfinies, comme (int) 'A' qui convertit un caractère en son code Unicode (entier). Pour cela les fonctions de conversion font bien l’affaire.

Il y a aussi les coercions d’un type plus générique vers un type spécialisé, notamment pour le type Object que l’on veut réinterpréter comme un type particulier. C’est une coercion dynamique dans le sens que Java vérifie que le type demandé est bien valide en cours d’exécution (grâce à la façon dont Java fait le polymorphisme). Si la coercion est invalide on a un ClassCastException.

Ce type de coercion ne résout pas le problème que je me posais, qui était, par exemple, de réinterpréter un entier comme une série d’octets ou tout autre arrangement qui convient. Pour qu’une telle coercion soit valide il faut simplement que le nouveau type occupe la même place en mémoire que l’original, ou même moins de place.

Le type union de C semble une bonne solution. De plus, il permet de définir non pas juste deux, mais n’importe quel nombre de types qui peuvent occuper le même emplacement mémoire. Le coût est qu’il faut une variable pour désigner l’union, puis si le type désiré contient plusieurs champs une autre variable dedans pour la structure. On se retrouve avec des constructions très imbriquées.

Je propose de se limiter à juste deux types simultanés. De plus, pour éviter les changements incontrôlés sur une valeur qui est normalement régie par des règles particulières, la valeur originale est copiée avant d’être utilisée dans l’union. Cette copie peut être retrouvée à l’aide d’une fonction de conversion. J’appelle le type union alias et la fonction de conversion unalias:

def n' = alias(n)
{
   byte[4] octets
}

.n'.octets[1] = n'.octets[3]
.n = n'    # conversion avec n'.unalias

Le problème est que l’on ne veut pas nécessairement exposer la représentation mémoire d’un objet, et surtout pas permettre de modifier un pointeur ou un attribut de taille en mémoire! On a déjà vu assez d’horreurs en C.

Comment peut-on s’assurer que la valeur retournée par alias ou par unalias est valide? Avez-vous des suggestions?