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!

Sans plus d’ambages, voici la méthode en question:

private void openStore() {
    try {
        store = RecordStore.openRecordStore("CALCULATOR", true);
        for (int recordId = 1, last = store.getNextRecordID(); recordId < last; recordId++) {
            byte[] record = null;
            try {
                record = store.getRecord(recordId);
            } catch (InvalidRecordIDException x) {
                // record was deleted
            }
            if (record == null) {
                continue;
            }
            Statement stmt = new Statement(recordId, record);
            try {
                Compiler compiler = new Compiler(stmt.text);
                Compiler.Expression expr = compiler.compile();
                if (expr instanceof Compiler.Declaration) {
                    ((Compiler.Declaration)expr).declare(bindings);
                }
                stmt.state = Statement.COMPILED;
            } catch (CompileError x) {
                stmt.state = Statement.ERROR;
            }

            statements.addElement(stmt);
        }
    } catch(Exception x) {
    }
}

On note trois blocs try, le plus extérieur d’entre eux se bornant à avaler toutes les exceptions qui pourraient échapper la partie intérieure.

Commençons par créer une méthode dodo. Cette méthode a des effets de bord, on ne peut donc pas recourir à la création d’une fonction ordinaire.

Pour mémoire une méthode dodo commence par method, suivi de son nom qui doit commencer en majuscule car l’on déclare un nouveau type. Dans notre cas on n’a pas besoin de variables ou de fonctions auxiliaires, alors le constructeur n’est pas défini dans le bloc de la méthode.

On écrit donc:

method OpenStore()
{
    ...
}

Maintenant écrivons le corps de la méthode. En première approximation nous allons essayer de reproduire exactement le code Java.

method OpenStore()
{
    try {
        .store = RecordStore.OpenRecordStore("CALCULATOR", true)
        loop for (int recordId, last = (1, store.getNextRecord);
                  recordId < last; ++.recordId) {
            byte[] record = null
            try {
                .record = store.getRecord(recordId)
            }
    ...
}

Pour affecter une valeur à la variable store, il faut en prendre sa référence; cela est marqué par un point devant son nom. Dans un effort pour réduire le nombre de noms réservés en dodo, toutes les boucles commencent par loop.

À ce point on arrive au premier bloc catch du programme. Mais dodo n’autorise pas à écrire un bloc catch à l’intérieur d’un autre bloc. Comment traduire le programme en dodo?

Regardons encore ce que fait le bloc catch en question dans le programme original:

            } catch (InvalidRecordIDException x) {
                // record was deleted
            }

Ce bloc ne fait rien, il se contente d’avaler silencieusement une exception InvalidRecordIDException. En assumant que getRecord ne jette pas une exception différente, on peut considérer tout ce qui suit comme faisant part d’un bloc finally.

Cela tombe bien, en dodo ce qui suit un bloc try est l’équivalent d’un bloc finally. Donc on peut continuer en ignorant le bloc catch:

method OpenStore()
{
    try {
        .store = RecordStore.OpenRecordStore("CALCULATOR", true)
        loop for (int recordId, last = (1, store.getNextRecord);
                  recordId < last; ++.recordId) {
            byte[] record = null
            try {
                .record = store.getRecord(recordId)
            }
            case if (record = null) {
                continue()
            }
            def stmt = Statement(recordId, record)
    ...
}

Ici on construit un nouveau Statement avec les paramètres de constructeur (recordId, record). Notez que l’on utilise pas new devant un constructeur. C’est ce qui permet aux méthodes d’être appelées comme des fonctions ordinaires, même si elles sont déclarées comme des types. De plus je n’ai pas spécifié le type de stmt. Si ce type correspond au type de retour de l’expression, il suffit d’utiliser « def » et dodo se charge de donner le type approprié à la variable.

On arrive maintenant à un nouveau bloc try. Cela ne devrait pas poser de difficulté particulière:

method OpenStore()
{
    try {
        .store = RecordStore.OpenRecordStore("CALCULATOR", true)
        loop for (int recordId, last = (1, store.getNextRecord); 
                  recordId < last; ++.recordId) {
            byte[] record = null
            try {
                .record = store.getRecord(recordId)
            }
            case if (record = null) {
                continue()
            }
            def stmt = Statement(recordId, record)
            try {
                def compiler = Compiler(stmt.text)
                def expr = compiler.compile
                case if (expr ~ ?Compiler.Declaration):
                    expr.Declare(bindings).
                .stmt.state = Statement.compiled
            }
    ...
}

On retrouve à nouveau le motif def variable = Constructeur(...), une notation à la simplicité bienvenue par rapport à Java. Le mot-clef case est utilisé pour tous les branchements conditionnels comme loop pour les boucles. Dodo a aussi la forme if ( ) ... else mais elle ne s’utilise que pour les expressions, l’équivalent de ( )? ... : en Java.

Le test du type de la variable se fait par correspondance de patron (pattern matching), où le patron est ici introduit par « ? » suivi du nom du type. On peut aussi insérer d’autres critères avant le point d’interrogation, par exemple pour tester la valeur d’un attribut de la variable.

Nous voici donc à nouveau devant un bloc catch qui suit un bloc try. Cette fois-ci peut-on l’ignorer comme s’il n’existait pas? Pas vraiment, cette fois-ci le bloc contient une instruction. Mais comme on arrive à la fin de la fonction il est peut-être raisonnable de décaler le bloc catch un peu plus bas, en-dehors des autres blocs. Voici ce que cela donne:

method OpenStore()
{
    try {
        .store = RecordStore.OpenRecordStore("CALCULATOR", true)
        loop for (int recordId, last = (1, store.getNextRecord);
                  recordId < last; ++.recordId) {
            byte[] record = null
            try {
                .record = store.getRecord(recordId)
            }
            case if (record = null) {
                continue()
            }
            def stmt = Statement(recordId, record)
            try {
                def compiler = Compiler(stmt.text)
                def expr = compiler.compile
                case if (expr ~ ?Compiler.Declaration):
                    expr.Declare(bindings).
                .stmt.state = Statement.compiled
            }
            statements.AddElement(stmt)
        }
    }
    catch (event: ?CompileError) {
        .stmt.state = Statement.error
    }
    ...
}

L’exception est comparée au patron fourni à catch, et si elle correspond le bloc est exécuté.

On voit un problème ici: l’instruction du catch fait appel à la variable stmt, qui n’est pas déclarée au plus haut niveau de la méthode. Mais dodo ne s’en formalise pas; si l’exception se produit là où la variable stmt est déclarée, alors l’instruction est valide. Ailleurs l’instruction produit une nouvelle exception. Si nécessaire, on peut restreindre le bloc catch aux exceptions jetées après une étiquette de notre choix ce qui permet d’éviter les variables non déclarées.

Il ne manque plus qu’à ajouter le bloc catch du try englobant qui avale toutes les exceptions. On obtient:

method OpenStore()
{
    try {
        .store = RecordStore.OpenRecordStore("CALCULATOR", true)
        loop for (int recordId, last = (1, store.getNextRecord);
                  recordId < last; ++.recordId) {
            byte[] record = null
            try {
                .record = store.getRecord(recordId)
            }
            case if (record = null) {
                continue()
            }
            def stmt = Statement(recordId, record)
            try {
                def compiler = Compiler(stmt.text)
                def expr = compiler.compile
                case if (expr ~ ?Compiler.Declaration):
                    expr.Declare(bindings).
                .stmt.state = Statement.compiled
            }
            statements.AddElement(stmt)
        }
    }
    catch (event: ?CompileError) {
        .stmt.state = Statement.error
    }
    catch {
    }
}

Certes ce programme correspond bien au programme Java initial, mais l’on a pas profité de toutes les possibilités de dodo en terme de gestion d’exception. Pour commencer, à quoi bon écrire un bloc try si il n’y a pas d’instructions à exécuter par la suite? Puisqu’un bloc catch n’est pas attaché à un bloc try particulier, la gestion d’exception intervient même s’il n’y a pas de try. Enlevons donc ce bloc try superflu:

method OpenStore()
{
    .store = RecordStore.OpenRecordStore("CALCULATOR", true)
    loop for (int recordId, last = (1, store.getNextRecord); 
              recordId < last; ++.recordId) {
        byte[] record = null
        try {
            .record = store.getRecord(recordId)
        }
        case if (record = null) {
            continue()
        }
        def stmt = Statement(recordId, record)
        try {
            def compiler = Compiler(stmt.text)
            def expr = compiler.compile
            case if (expr ~ ?Compiler.Declaration):
                expr.Declare(bindings).
            .stmt.state = Statement.compiled
        }
        statements.AddElement(stmt)
    }
    catch (event: ?CompileError) {
        .stmt.state = Statement.error
    }
    catch {
    }
}

Ensuite on voit là un motif intéressant:

        def stmt = Statement(recordId, record)
        try {
            ...
        }
        statements.AddElement(stmt)

Ici on initialise la variable stmt, on exécute un bloc try, puis finalement on ajoute la variable à une liste à l’aide d’une seule instruction. Cette dernière s’exécute aussi bien en cas de succès qu’en cas d’exception.

Dodo propose une notation spéciale pour ce motif qui rend le programme plus succinct. L’instruction finale remonte au niveau de l’instruction d’initialisation, et tout ce qui suit fait partie d’un bloc try implicite. Je l’utilise dans le programme ci-dessous.

method OpenStore()
{
    .store = RecordStore.OpenRecordStore("CALCULATOR", true)
    loop for (int recordId, last = (1, store.getNextRecord);
              recordId < last; ++.recordId) {
        byte[] record = null
        try {
            .record = store.getRecord(recordId)
        }
        case if (record = null) {
            continue()
        }
        def stmt = Statement(recordId, record) ...> statements.AddElement(stmt)
        def compiler = Compiler(stmt.text)
        def expr = compiler.compile
        case if (expr ~ ?Compiler.Declaration):
            expr.Declare(bindings).
        .stmt.state = Statement.compiled
    }
    catch (event: ?CompileError) {
        .stmt.state = Statement.error
    }
    catch {
    }
}

Enfin, on peut se débarrasser du dernier try en remarquant que le continue ne s’exécute que si getRecord a jeté une exception, auquel cas un bloc catch peut intervenir. Au lieu de placer un continue dans ce bloc catch, je vais utiliser resume avec une étiquette judicieusement placée pour passer à l’itération suivante de la boucle.

method OpenStore()
{
    .store = RecordStore.OpenRecordStore("CALCULATOR", true)
    loop for (int recordId, last = (1, store.getNextRecord);
              @cond recordId < last; ++.recordId) {
        def record = store.getRecord(recordId)
        def stmt = Statement(recordId, record) ...> statements.AddElement(stmt)
        def compiler = Compiler(stmt.text)
        def expr = compiler.compile
        case if (expr ~ ?Compiler.Declaration):
            expr.Declare(bindings).
        .stmt.state = Statement.compiled
    }
    catch (event: ?InvalidRecordIDException) {    # record was deleted
        ++.recordId
        resume @cond
    }
    catch (event: ?CompileError) {
        .stmt.state = Statement.error
    }
    catch {
    }
}

En obligeant les blocs catch à se situer en-dehors des autres blocs, et à l’aide d’autres astuces de notation, dodo permet d’écrire des instructions qui ne se mélangent pas avec la gestion des cas exceptionnels. Le programme y gagne en clarté et en concision.

Ne nous attardons pas plus longtemps sur les détails triviaux. Voyons ce que le terme signifie en informatique.

Le currying transforme une fonction qui s’applique à une liste de paramètres:

f(x, y, z)

en une fonction qui s’applique à un seul paramètre, qui retourne une autre fonction à un paramètre, etc jusqu’à consommer tous les paramètres.

f(x) -> f'(y) -> f''(z)

En dodo cette transformation se fait en remplaçant les paramètres de la fonction avec des caractères de soulignement _.

def g = f(_, _, _)

On peut appeler cette fonction avec trois paramètres de la façon suivante:

g(1)(3)(n) 	# = f(1, 3, n)

Quel est l’avantage de faire cela? Et bien cela permet d’appeler g avec un seul ou deux paramètres, et réutiliser la fonction résultante comme une fonction ordinaire. Dans un langage qui n’utilise que les fonctions curriées cela donne des propriétés intéressantes.

Dodo n’est pas un tel langage mais l’option est là.
Une autre utilisation du caractère de soulignement est d’appeler une fonction avec des paramètres renseignés à l’avance, par exemple:

def normalise = min(_, 100)
.x = normalise(x)	# contraint x à être inférieur ou égal à 100

Cela peut aussi servir à composer des fonctions:

def positive_sinus = abs(_) & sin(_)
positive_sinus(-0.5)	# = sin(abs(-0.5))

Ici « & » sert à combiner les deux fonctions en une nouvelle fonction, qui les applique dans l’ordre à l’argument. Cela ne marche pas avec les fonctions ordinaires, il faut utiliser _.

Voyons quelques scénarios possibles:

A.
  try {
    throw ExceptionA()
  }
  throw OtherException()

B.
  try {
    return x
  }
  throw ExceptionB()

C.
  try {
    throw ExceptionC()
  }
  return y

A. Masquage d’exception

Dans le cas A, les instructions de finalisation jettent une autre exception après que le bloc try ait déjà fait de même. Dans ce cas les instructions de finalisation s’interrompent et la fonction jette une exception. En Java, l’exception jetée serait OtherException mais ce n’est pas une bonne solution. En effet, l’important est avant tout ce qui est arrivé auparavant à l’intérieur du bloc try. Dodo, pour sa part, retourne l’exception ExceptionA. Mais ce n’est que le premier événement de la chaîne d’événements et l’on peut aussi obtenir la valeur de OtherException dans le code appelant.

Voici un résumé de l’exécution:

1.  try {
2.    throw ExceptionA()

Ici le contrôle échappe du bloc try, et continue dans les instructions de finalisation:

3.  throw OtherException()

Maintenant les instructions de finalisation ne peuvent plus continuer.
La fonction termine avec une exception, retournant la chaîne d’événements:

  ExceptionA, OtherException.

Le code appelant voit ExceptionA en tête de la chaîne d’événements.

B. Exception piégée par un return

Dans le cas B, le bloc try termine en retournant une valeur x. Dans ce cas on pourrait argumenter que l’exception levée dans les instructions de finalisation est plus importante que la valeur de retour, mais ce n’est pas l’approche de dodo. En dodo, l’exécution des instructions de finalisation s’interrompt à l’exception et la fonction retourne la valeur x. Cependant, lors de la compilation il y a un message d’avertissement si les exceptions levées par le code de finalisation ne sont pas gérées dans un bloc catch alors que le bloc try contient un return.

Pour éviter l’avertissement il faut gérer les cas exceptionnels dans les instructions de finalisation. Notez tout de même que dodo ne permet pas d’altérer le résultat final, qui est le retour de x à la fin de la fonction.

Un résumé de l’exécution pour cas B:

1.  try {
2.    return x

Ici le contrôle échappe du bloc try, et continue dans les instructions de finalisation:

3.  throw ExceptionB()

Maintenant les instructions de finalisation ne peuvent plus continuer.
Cependant le résultat de la fonction était déjà décidé avant, lorsque return a été appelé.
L’exception ExceptionB ne sort donc pas de la fonction. On dit qu’elle est piégée.

C. Instruction return tardive

Dans le cas C, les instructions de finalisation appellent return alors qu’une exception a été levée avant:

  try {
    throw ExceptionC()
  }
  return y

L’exception gagne, et la fonction termine en exception. Mais la valeur de retour est ajoutée à la chaîne d’événements. Le code appelant voit donc:

  ExceptionC, return(y).

On peut aussi envisager un cas D où le bloc try et le code de finalisation tous deux retournent une valeur. Dans ce cas la première valeur est retournée et le second return est piégé. Cela ne génère pas de message d’avertissement, bien que ce soit bien entendu peu recommandé.

Que se passe-t-il dans un exemple simple?

Prenons le code suivant:

   def f(n) =
      if (n < 7)
         1 + f(n+1)
      else
         n

Dodo est basé sur le passage de continuations. Ici les deux continuations pour le if sont:

   1 + f(n+1)

et

   n

Donc l’instruction if… else… doit examiner la condition (n < 7), et en fonction de son résultat choisir la continuation qui correspond.

La logique s'apparente à:

   # Calculer la valeur de vérité
   n  résultat
   # Choisir une continuation
   match(résultat, true) ->
      1 + f(n+1)
   |
      n;;

Mais on peut faire mieux. Imaginons que l’opération de comparaison < ne retourne pas une valeur de vérité, mais plutôt choisit une continuation. Transformer cela en valeur de vérité revient à:

   n 
      true
   |
      false;

Voyez-vous où j’en viens? Pour la construction if… else… il suffit de remplacer les continuations dans l’expression ci-dessus. Soit:

   n 
      1 + f(n+1)
   |
      n;

La construction if (a < b) ... else ... peut être traduit en forme avec continuations par une simple transformation, comme décrit ci-dessus.

Je vais appeler la fonction qui correspond à l'opérateur <, "lessThan". Le type de la fonction classique pour les entiers est:

   Fun(int,int->bool)

Le type de la fonction basée sur les continuations est en dodo:

   Fun(int,int->(),())

Et on pourrait l’écrire un peu comme:

   def lessThan = fun (int a, b) -> yes(), no()
   {
      {- Code pseudo-assembleur -
         COMPARE(a,b)
         IFNEGATIVE yes()
         no()
      -}
   }

C’est simple et efficace.

Eh bien grâce à une suggestion que l’on m’a faite, il semble que j’aie finalement la solution.

Pour pouvoir exécuter un programme dodo, le plus simple serait probablement d’écrire un interpréteur. Cependant j’anticipais des difficultés certaines avec cette approche et comme il faudra de toute façon écrire un jour un compilateur pour questions de performance, le jeu n’en vaut pas la chandelle.

Donc je voulais écrire un compilateur. Celui-ci va prendre en entrée un programme dodo, et produire en sortie un programme que l’ordinateur peut exécuter. L’ordinateur exécute les instructions en langage machine, mais on passe généralement par l’assembleur pour le générer. Très bien. Seulement je ne suis pas exactement confortable avec l’assembleur; la recherche d’un expert pour m’aider s’est conclue en rentrée bredouille.

Il y a d’autres solutions. Par exemple, la JVM (le programme qui exécute Java) possède un assembleur simplifié, de même pour LLVM. Cependant ces assembleurs ont l’inconvénient de ne pas offrir le GOTO. Certes, l’instruction GOTO n’est pas appropriée pour un langage de haut niveau qui se doit d’être maintenable, mais son absence d’un langage de très bas niveau comme un assembleur me chagrine.

J’ai découvert que le langage C, dans la version étendue de gcc, permet le GOTO local à une procédure. J’ai pu l’utiliser pour traduire un petit programme « HelloWorld » de dodo en C. Il semblait y avoir une possibilité de traduire automatiquement les programmes dodo en C et de les compiler grâce à gcc, ce qui me convenait bien. Cependant le GOTO de gcc est limité à 255 labels ce qui n’est pas suffisant pour dodo.

Une autre idée est de remplacer le GOTO par un SWITCH, et en effet on peut aller plus loin de cette façon. Mais à ce point je me préoccupait déjà de la gestion de la mémoire pour les variables et cette approche n’était pas des plus prometteuses.

C’est alors qu’en visite auprès de ma famille, un parent (merci Romain!) à qui je parlais de dodo m’a suggéré les pointeurs de fonction. C’était suffisant pour m’orienter vers une nouvelle solution.

D’un autre côté, même si un tel constructeur n’est pas défini pour la classe, l’initialisation d’un attribut de l’instance ou de la classe peut causer le chargement d’une autre classe. Le chargement de cette autre classe n’est pas toujours sans effets de bord.

Pour conserver la propriété « libre d’effets de bord » de la fonction, il est nécessaire de charger la classe sans effets de bord. Cela signifie que si la classe en question possède un constructeur sans paramètres, ou que l’une des classes utilisées par cette classe doit être chargée avec des effets de bord, la classe ne peut pas être complètement initialisée dans la contexte de la fonction.

En conséquence une fonction peut terminer en erreur simplement du fait qu’elle déclare un objet d’une classe qui n’a pas été initialisée.

Pour éviter que cela n’arrive il faut charger la classe en mémoire dans un constructeur appelé avant la fonction. Par exemple, il pourrait être le constructeur de la classe qui contient la fonction, ou le corps principal du programme ou d’une librairie.