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 }

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?

Pour utiliser une variable dans plusieurs fonctions en parallèle, il faut la déclarer partagée. De cette façon elle peut être modifiée de façon atomique (sans état intermédiaire) par ces fonctions. Un exemple de déclaration est:

Share(<this: Personne>) externe

Il faut utiliser le service share (voir passage de message) pour modifier la variable, par exemple:

.share!externe = inspecteur
share!externe.Visite(site)

Il faut comprendre cela comme si le programme envoie des commandes à la variable partagée, en fait il n’attend pas que l’opération soit effectuée (ou cause une erreur).

L’envoi de commande peut produire un ou plusieurs résultats. Ces résultats deviennent disponibles au plus tard quand la méthode correspondante termine. D’ici là l’accès aux résultats est une opération bloquante.

Si une commande fait intervenir plusieurs variables dont la valeur n’est pas encore connue, elle commence à être évaluée seulement après que la valeur pour chacune d’elles est renseignée (progression en tout ou rien).

Les attributs de la variable partagée peuvent être accédés comme une variable normale. Si la variable a plusieurs états possibles, et son état courant ne donne pas accès à l’attribut en question, alors la tâche courante bloque en attendant que la variable change d’état.

Par exemple:

def Inspecteur = new Personne
{
   __state incognito =>
      # On ne révèle rien ici

   __state officiel =>
      Matricule matricule
}
...
.share!externe = Inspecteur()
...
Matricule m = externe.matricule

La tâche courante bloque jusqu’à ce que l’inspecteur sorte de son incognito et devienne officiel. Pour une variable normale, on obtiendrait immédiatement une erreur.

Le service share garantit que les opérations qu’il gère s’exécutent dans l’ordre où elles apparaissent dans le programme (ordre séquentiel) pour une tâche donnée.

Le bloc fork

Si l’on veut poursuivre d’autres tâches en attendant qu’une variable soit renseignée, il faut mettre l’opération bloquante dans un bloc sync ou fork (les instructions d’un fork sont comprises dans un block sync implicite):

fork
{
   Matricule m = externe.matricule
   # utilise m...
}
# reste des opérations...

Cela permet en particulier de créer des gestionnaires d’événement, dans le cas ci-dessus pour le changement d’état de l’inspecteur. Notez qu’un bloc fork ne commence à s’exécuter que lorsque toutes les variables qu’il utilise sont renseignées. Si l’on ne veut pas attendre d’avoir une valeur pour une variable particulière, il faut utiliser un bloc fork (ou sync) imbriqué. Par exemple:

def _approuvé = share!principal.Approuve("Vérification du matricule inspecteur")
fork
{
   Matricule m = externe.matricule
   case:
      registre.contains(m) =>
         def data = registre[m]
         # utilise data...
      else =>
         fork: # Regarder si vérif approuvée ici seulement
            case if (_approuvé)
            {
               # Pas sur le registre! Faire quelque chose...
            }
         .
      }
   .
}

On peut écrire un gestionnaire d’événements multiples avec la forme spéciale fork select, qui s’apparente à un bloc case où les instructions correspondantes s’exécutent dans un fork quand la condition (garde) devient vraie. Le bloc fork select continue de s’exécuter jusqu’à ce que le système devienne stable, c’est-à-dire que toutes les variables ont une valeur connue.

La variable qui signale la fin du programme est runtime.process.exit. Si celle-ci est utilisée comme garde d’un fork select, le gestionnaire d’événements s’exécute jusqu’à la fin du programme.

Partie 1 – Présentation
Partie 2 – Le passage de messages
Partie 4 – Les transactions

Malgré les apparences, je ne suis pas resté complètement oisif.

Documentation
Pour une part j’ai commencé à mettre à jour la documentation du langage. Dites-moi ce que vous en pensez!

Dodo – Introduction (anglais)

Implémentation
J’ai aussi fait des tentatives d’implémentation de dodo en d’autres langages. Je reparlerai de la version C une autre fois. Pour le moment, je vous invite à regarder cette adaptation du modèle objet de dodo à Javascript (incomplet):

Source de la page

Si vous regardez tout en bas du source, vous verrez un petit programme d’exemple qui fait appel à ce modèle objet adapté de dodo.

Je donne ici les correspondances de terme:

             Dodo                |            Javascript
_________________________________|________________________________
                                 |
 struct                          | struct
                                 |
 self                            | this
                                 |
 new var0(x: 1) {def z = 36}     | copy(var0, 'x', 1, {z: 36})
                                 |
 ^fonc                           | $fonc
                                 |
 class A {def coul="bleu"}       | var A = new Class({coul: "bleu"});
                                 |
 class B {B(n) {print(n)}}       | var B = new Class({}, {1: function(n)
                                 |         {print(n);}});
                                 |
                                 |   NOTE: "1" est le nombre d'arguments
                                 |   du constructeur
                                 |
 def C = new A {def p = 0}       | var C = new A.constructor({p: 0});
                                 |
 B(1000)                         | new B(1000)
                                 |

J’ai bien tenté de rendre les variables construites par ce modèle non éditables comme en dodo mais celà fait appel au nouveau standard ECMAScript et mes connaissances de Javascript sont limitées.

La programmation parallèle peut faire appel à la notion de transaction pour manipuler les variables partagées. Le principal intérêt de ce modèle est la simplicité d’utilisation et une efficacité meilleure que d’autres modèles comparables.

1. Les transactions

   Une transaction en dodo est délimitée par un bloc sync qui contient les instructions qui font partie de la transaction. Ces instructions sont exécutées comme si il n’y avait pas de parallélisme et nulle autre tâche n’interfère avec son exécution.

   En réalité ce n’est pas tout à fait vrai, par défaut dodo triche pour éviter le rollback des transactions. En effet si le système détecte qu’une transaction ne peut pas être complétée « comme si nulle autre tâche n’interfère », pour bien faire il faut annuler tout ce que la transaction a fait jusqu’ici et recommencer du début! C’est ce qu’on appelle un rollback.

   Nous verrons plus tard comment changer les options pour autoriser à nouveau les rollbacks et se conformer au principe d’isolation. Voyons maintenant un exemple de bloc sync:

   sync
   {
      .a = a + b
   }
   

   Pourquoi veut-on créer une transaction juste pour ajouter deux variables?

   Eh bien si on y pense, il se pourrait qu’une autre tâche intervienne entre le moment où les variables sont lues et le moment où a est mise à jour, ce qui fait que la valeur finale ne sera pas vraiment a + b. L’utilisation d’une transaction permet de protéger le bloc de code des influences extérieures.

   Pour prendre en compte la possibilité de rollback, il convient d’indiquer à dodo comment annuler les changements déjà faits. Si par exemple f(a) cause un rollback on peut écrire:

   sync
   {
      .a = a + b ...> __undo .a = a - b
      f(a)
   }
   

   Note: Les instructions précédées de __undo sont aussi exécutées en cas d’exception, sauf si le gestionnaire d’événements convertit l’exception en return. Un bloc sync définit son propre gestionnaire d’événements.

2. Les variables versionnées

   Les variables partagées ordinaires ne sont pas de grande utilité dans le cadre des transactions, car leurs modifications sont généralement problématiques à annuler en cas de rollback. C’est pourquoi on fait appel aux variables versionnées. Les modifications d’une variable versionnée sont automatiquement annulées en cas de rollback.

   Une variable versionnée a une partie commune, partagée entre toutes les tâches, et une partie locale qui est utilisée dans le cadre d’une transaction. Quand la variable est lue dans une transaction, la partie partagée est copiée dans la partie locale ainsi que son numéro de version. C’est ce qui permet à sa valeur de rester consistante tout au long de la transaction, même si une autre tâche intervient.

   Quand la transaction a copié la valeur partagée de la variable dans sa partie locale, la variable est dans l’état synchronized.

3. Les options de synchronisation

   Par défaut, dodo garantit que la transaction a une vue cohérente des données: il existe un moment dans le temps où toutes les variables de la transaction ont la valeur que la transaction a lue. C’est la seule garantie des options par défaut (use: newest). Pour l’exemple précédent, si a vaut 0 et b vaut 3 au départ, et il y a trois tâches qui exécutent la transaction en parallèle, la valeur finale de a peut être 9, 6 ou bien 3. Il se peut même qu’elle aille de 6 à 3 (inversion temporelle).

   Exemples d’exécution
   Valeur lue par la troisième tâche en vert, valeur écrite par la troisième tâche en gras
   
   temps —–>
   a: 0 , 3 , 6 , 9
   temps —–>
   a: 0 , 3 , 6 , 6
   temps —–>
   a: 0 , 3 , 6 , 3

   Si l’on veut assurer la consistence temporelle, et s’assurer que la variable a des valeurs qui se suivent de façon logique dans le temps, on peut choisir l’option suivante:

   __handle (use: first)
   

   Cela indique à dodo que la valeur ne devrait pas être remplacée si la version utilisée par la transaction n’est plus celle que contient la variable partagée. Une fois encore, cette option ne cause pas de rollbacks.

   Cependant, avec ceci il se peut qu’une variable soit mise à jour alors qu’une autre ne l’est pas — la transaction n’assure pas vraiment la cohérence des données mises à jour. C’est pourquoi dodo ne garantit pas une vue cohérente des données avec cette option.

   Effet de l’option use: first sur les conflits de version avec une transaction parallèle (en vert)

   sync
   {
      .a *= b
      ++.b
   }
   
   Val. lue/écrite     a  b  |  a  b  |  a  b
   -  -  -  -  -  -  -  -  -  -  -  -  -  -  -
   Début transaction   3  2  |  3  2  |  3  2  
   Fin transaction     5  2  |  3  4  |  3  2
   Valeur locale       6  3  |  6  3  |  6  3
   -  -  -  -  -  -  -  -  -  -  -  -  -  -  -
   Valeur partagée     5  3  |  6  4  |  6  3
   -  -  -  -  -  -  -  -  -  -  -  -  -  -  -
   

   Pour obtenir davantage de garanties il faut autoriser les rollbacks. Le premier exemple de transaction avec rollback est avec les options:

   __handle (use: newest, action: fail)
   

   Ces options sont similaires aux options par défaut, mais si dodo détecte une inversion temporelle les opérations sont annulées et la transaction s’exécute à nouveau. Dans les exemples d’exécution précédents le dernier ne serait pas possible.

   Finalement, ces options apportent toutes les garanties que l’on peut attendre d’une transaction:

   __handle (use: first, action: fail)
   

   Cela indique à dodo que la transaction doit être réexécutée si la version utilisée par la transaction n’est plus celle que contient la variable partagée quand elle est mise à jour. De plus ces options assurent une vue cohérente des données. Dès lors la seule exécution possible est:

   a: 0 3 6 9

   Les options de synchronisation peuvent s’appliquer à une variable particulière avec la notation __handle variable.

4. Bloc sync conditionnel

   Le bloc sync conditionnel s’écrit:

   sync select
   {
      condition1 =>
         ...transaction1...
      condition2 =>
         ...transaction2...
      ...
   }
   

   Les variables utilisées dans la condition font partie de la transaction. Si les conditions sont réunies mais par la suite, la transaction sélectionnée fait un rollback, alors dodo teste les conditions de la transaction suivante. Si nulle transaction n’a de succès, alors le bloc sync entier fait un rollback. Une erreur est signalée si aucune transaction n’a été tentée dans un bloc sync conditionnel.

   La condition spéciale default indique qu’aucune autre condition n’est remplie; de fait, la condition default n’est pas remplie si l’exécution d’une autre transaction a été tentée mais s’est soldée par un rollback. L’utilisation de default permet d’assurer qu’au moins une transaction est tentée.

5. Transaction à l’intérieur d’une transaction

   Si le bloc sync se trouve à l’intérieur d’un autre bloc sync, cela définit une sous-transaction. Les changements faits dans la sous-transaction ne sont effectifs que quand la transaction englobante termine avec succès. En cas de rollback de la sous-transaction, la transaction englobante fait aussi l’objet d’un rollback. Le reste dépend des options de synchronisation.

   Avec les options de synchronisation par défaut (use: newest), dodo assure une vue cohérente des données de la sous-transaction à un moment dans le temps. Mais celle-ci peut différer de la vue de la transaction englobante.

   Avec l’option de consistance temporelle (use: first), la vue de la transaction englobante est réutilisée.

   Si les rollbacks sont autorisés en cas d’inversion temporelle (use: first, action: fail), l’inversion temporelle est détectée quand une variable est lue ou mise à jour dans la sous-transaction.

   Finalement avec toutes les garanties en place (use: first, action: fail), la vue de la transaction englobante est réutilisée. La version des variables de la sous-transaction est testée quand elles sont mises à jour.

   Note: Une variable versionnée est synchronisée avant d’être passée en paramètre à une fonction contenant potentiellement une transaction.

Les blocs sync conditionnels et emboîtés permettent la composition de transactions.

Partie 1 – Présentation
Partie 2 – Le passage de messages
Partie 3 – Les tâches et les variables partagées

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.

Je ne vais pas poursuivre l’analogie du navigateur Internet plus loin. Mais vous pouvez la garder en tête quand je vais discuter le passage de message dans dodo, car les deux se rejoignent parfois.

Dodo utilise un modèle client-serveur pour la programmation parallèle. Le partage de données se fait par envoi de messages, ce qui évite les problèmes de synchronisation liés à la mémoire partagée.

Le client

L’envoi d’un message se fait de la façon suivante:

service!capability.Message(arguments)

service est le nom du service requis, par exemple net désigne un service lié au réseau.
capability est un objet qui donne accès à un certain aspect du service, par exemple la communication avec une adresse choisie.
Message est le nom du message envoyé, par exemple Get pour demander le contenu à une adresse.
arguments est une liste de données qui font partie du message, par exemple un nom de page web.

Pour recevoir le contenu de la page d’accueil de dodo, on peut faire:

def dodohome = net.Connection("http://dodo.sourceforge.net")
def contenu = net!dodohome.Get("index.html")

À partir de cet instant, on peut utiliser la variable contenu dans le programme. Cependant, sa valeur est future, ce qui signifie qu’elle n’est connue qu’à partir du moment où le service a répondu au message. Si l’on tente de lire sa valeur avant cela le programme va s’interrompre jusqu’à ce qu’elle soit disponible.

On peut définir un gestionnaire pour la variable à l’aide de handler, qui permet de limiter le délai de réponse, ou demander à dodo de répéter la requête si la réponse n’est pas retournée à temps.

Dans l’exemple précédent, la capability est obtenue juste avant son utilisation. Souvent une capability est reçue en paramètre de la fonction. En effet les fonctions dodo, que l’on distingue des méthodes, n’autorisent pas les effets de bord. L’utilisation d’une capability permet de contourner cette limitation.

Le serveur

Un serveur est un programme dodo qui est enregistré pour délivrer un certain service. Il offre aussi le moyen d’obtenir des capabilities qui permettent de s’assurer que le message provient d’un client autorisé.

Le serveur est démarré quand un client lui fait une requête, et peut être arrêté ou continuer en fonction des ressources disponibles et de son utilisation.

L’exemple ci-dessous illustre la définition d’un service. Dans cet exemple les possibilités de programmation parallèle apportées par les modèle client-serveur ne sont pas exploitées.

__Service__ exemple
export capability DireHello:
    String nom

    message Parle(Link(<with: DireHello>) ressource)
    {
        console!Stdout().Puts("Hello, " + ressource.nom)
    }
.

__Module__ program
__Main__
def Main()
{
    def helloworld = new DireHello.instance(nom: "world")
    exemple!helloworld.Parle()
}

Partie 1 – Présentation
Partie 3 – Les tâches et les variables partagées
Partie 4 – Les transactions

Les langages généralistes les plus répandus comme C, C++, Java, Visual Basic ou C# utilisent le modèle des tâches d’exécution (threads) avec mémoire partagée comme base du parallélisme. Ce modèle est en bonne adéquation avec le fonctionnement des processeurs. De plus, ces langages proposent (sous forme de bibliothèque) des outils pour le passage de messages entre processus. Cela peut aussi être utilisé pour la communication entre tâches à l’intérieur d’un même processus.

Le problème de la mémoire partagée c’est qu’elle induit des difficultés pratiquement insolubles aux programmeurs qui veulent l’exploiter. Il y a de bonnes chances de créer des situations ou la performance chute, ou bien deux tâches s’attendent indéfiniment l’une l’autre à cause de verrous mis en place pour protéger l’intégrité de la mémoire partagée. Pour y remédier on a inventé des mécanismes sans verrou, qui ont leurs propres problèmes et ne peuvent être utilisés partout.

Pour dodo j’ai préféré privilégier un autre modèle, celui du passage de messages. Il est toujours possible d’avoir deux tâches qui s’attendent indéfiniment (deadlock) mais ce modèle a la réputation d’être plus facile à utiliser et de causer moins de soucis aux programmeurs.

J’ai aussi prévu d’intégrer un modèle de mémoire partagée qui a l’avantage de détecter les situations de blocage, celui proposé par le projet Athapascan du laboratoire ID-Imag. Chaque modèle a ses avantages et je pense que dodo peut bénéficier de la combinaison de ces deux approches.

Je parlerai aussi des variables versionnées et des transactions, des concepts importants pour les applications concurrentes.

Partie 2 – Le passage de messages
Partie 3 – Les tâches et les variables partagées
Partie 4 – Les transactions

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.