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.

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?

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

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

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 _.

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

Dès lors, on peut considérer une valeur de vérité comme un ensemble de taille maximale un.

L’ensemble vide [] signifie faux et l’ensemble avec un élément [v] signifie vrai. Il est aisé de relier les opérations sur les ensembles aux opérations booléennes:

Union (conjonction OU)

quel que soit E: E union E = E
[] union [v] = [v]
[v] union [] = [v]

Table de vérité:

 a   b | a OU b
_______|_____
 0   0 |  0
 0   1 |  1
 1   0 |  1
 1   1 |  1

Intersection (disjonction ET)

quel que soit E: E intersection E = E
[] intersection [v] = []
[v] intersection [] = []

Table de vérité:

 a   b | a ET b
_______|_____
 0   0 |  0
 0   1 |  0
 1   0 |  0
 1   1 |  1

Complément (négation NON)

complément [] = [v]
complément [v] = []

Table de vérité:

 a | NON a
___|_____
 0 |  1
 1 |  0

Différence symétrique (disjonction exclusive XOR)

quel que soit E: E différence symétrique E = []
[] différence symétrique [v] = [v]
[v] différence symétrique [] = [v]

Table de vérité:

 a   b | a XOR b
_______|_____
 0   0 |  0
 0   1 |  1
 1   0 |  1
 1   1 |  0

On voit que les relations sont les mêmes pour les valeurs ensemblistes [], [v] et les valeurs de vérité 0, 1.

Dans dodo, qualifier Logic apporte les opérations || (OU/union), && (ET/intersection), ! (NON/complément) et ^^ (XOR/différence symétrique). Il s’applique à la fois aux booléens, aux intervalles et aux ensembles.

Une représentation efficace d’un ensemble dont l’ensemble d’éléments possibles est limité est un entier. Chaque bit de l’entier correspond à un élément possible. Si le bit vaut 1 l’élément est présent mais s’il vaut 0 l’élément est absent.

Dans le cas du booléen considéré comme un ensemble décrit ci-dessus, l’ensemble des éléments possibles se limite à un seul: v. Il suffit donc d’un bit pour représenter le booléen.

En utilisant le bit le moins significatif, on obtient la représentation suivante:

[] = 0x0000 = 0
[v] = 0x0001 = 1

Si bien que faux vaut 0, et vrai vaut 1! Si vous êtes familier avec C ou un autre langage qui a repris la même convention cela ne devrait pas vous surprendre. De fait c’est une notation largement acceptée en logique.

Puisque dodo est basé sur les continuations, il est évident que ce serait une première chose à inclure dans dodo minimal.

Pour rappel, une continuation est un point du programme que l’ordinateur peut exécuter, en lui passant les données appropriées. Une continuation n’a pas de notion de « retour » ce qui la différencie d’une fonction. Mais si l’une des données passées est elle-même une continuation qui représente le reste du programme, on peut l’utiliser comme une fonction. C’est le principe de base de dodo.

Puisqu’il suffit d’avoir la définition d’une continuation dans le langage pour ouvrir la porte aux fonctions le dodo minimal devrait la posséder. Comme je l’ai discuté par ailleurs, cela ne sera pas accessible dans le langage dodo normal.

Voici comment cela pourrait apparaître dans dodo minimal:

(-> x, return
return(x))

Le code ci-dessus définit une continuation qui prend une valeur, x, et une continuation return. Elle est l’équivalent d’une fonction qui retourne simplement x (fonction identité).

L’utilisation d’une continuation est déjà décrite dans la documentation du langage et fait appel aux opérateurs -> et |.

Un autre élément indispensable est celui qui permet le branchement, c’est-à-dire le choix des instructions à exécuter en fonction d’une condition. C’est l’opérateur match de dodo.

Pour permettre l’extension du langage, il faudra aussi <wrap> et template comme décrit dans un précédent article.

Cela ne serait pas suffisant pour définir le langage dodo complet; en particulier, il faudrait ajouter le chargement des classes, les constructeurs, les références (opérateur .) pour la partie objet impérative, et d’autres opérateurs pour la partie programmation parallèle.

Mais ces simples éléments pourraient déjà servir de base à une large partie de dodo.

Il se trouve que dodo a déjà deux mécanismes qui pourraient être réutilisés: les intercepteurs d’appel (wrap) et les templates. Voici un exemple de ce que l’on pourrait faire avec s’ils étaient utilisés pour les macros.

Le but de cet exemple est de transformer une forme impérative (boucle while) en une forme à continuations.

Par exemple, je veux transformer:

loop while (x > 2.0)
{
   .x = (x + e) * k
}

en:

fun: x -> ret(double)
   if (x > 2.0)
      (x + e) * k -> x
      $loop1(x)
   else
      ret(x)
.
-> loop1
loop1(x)

Ce code est l’équivalent de la boucle while en CPS.

Ma proposition utilise wrap pour définir la syntaxe de la boucle while et les actions associées, et template pour transformer la syntaxe.

Commençons notre exemple. D’abord on va définir une expression régulière qui correspond à la syntaxe de la boucle while:

/loop while
\(\n $cond\n \)(
{\n $body\n } | :\n $body\n \.[ \n])/

Dans l’expression régulière, j’utilise un espace pour dénoter que l’on peut mettre des espaces ou tabulations, et un saut de ligne ou \n pour indiquer que l’on peut mettre des espaces, tabulations ou sauts de lignes. Soit [ \t]* et [ \t\n\r]* respectivement.

Les syntaxes acceptées sont
loop while (cond) {body}
et
loop while (cond): body.

Quand le compilateur rencontre cette syntaxe, les variables cond et body prennent une valeur et une action est exécutée. Je définis un template loop_while qui est l’action utilisée pour transformer la syntaxe. Son invocation sera:

   loop_while(
      use (body.inVars + cond.inVars) * body.outVars,
      set body.outVars,
      while cond,
      do body)

Les paramètres de loop_while sont:

• use les variables d’entrée de la boucle. Ce sont les variables utilisées par le corps et les variables utilisées par la condition qui sont aussi modifiées par le corps de la boucle.
• set les variables de sortie de la boucle. Ce sont les variables modifiées par le corps de la boucle.
• while la condition.
• do le corps de la boucle

Voici le code complet.

/loop while
\(\n $cond\n \)(
{\n $body\n } | :\n $body\n \.[ \n])/
{
   loop_while(
      use (body.inVars + cond.inVars) * body.outVars,
      set body.outVars,
      while cond,
      do body)
}


def template loop_while(use $inVars, set $outVars, while $cond, do $body) =
   fun: inVars -> ret(outVars.types)
      if (cond)
          body -> outVars
          $loop1(inVars)
      else
          ret(outVars)
   .
   -> loop1
   loop1(inVars)

Voici comment fonctionne le code dans la forme à continuations.

  fun: inVars -> ret(outVars.types) 

Définit une fonction lambda qui prend en paramètre inVars et retourne outVars.

    if (cond) 
      body -> outVars
      $loop1(inVars) 

Si la condition est vraie, exécute le corps de la boucle puis fait un appel récursif à la fonction lambda avec inVars comme arguments.

    else 
      ret(outVars) 
  .

Sinon, retourne outVars.

  -> loop1 
  loop1(inVars)

Enfin, met la fonction lambda dans une variable loop1 puis appelle la fonction avec inVars comme arguments.

Nous allons maintenant voir comment dodo interprète la notion de classe, un classique de programmation orientée objet, en terme de prototypes.

Classe

Une classe définit un modèle auquel tous les objets instance de la classe répondent. En pratique, une classe dodo définit des attributs et fonctions membres de la classe ainsi qu’un prototype. Les objets instance de la classe dérivent de ce prototype.

Le nom d’une classe commence toujours avec une lettre majuscule.

Un exemple de classe serait Maison, dont maisonDesDupont serait une instance. Le prototype sur lequel est basé maisonDesDupont est Maison.instance, comme les autres objets instance de la classe.

La classe est elle-même un objet qui peut avoir des attributs et fonctions membres. Par exemple, instance est un attribut standard d’une classe.

Une classe possède également des constructeurs et des fonctions fabrique d’objet.

Constructeur

Un constructeur initialise un objet instance de la classe. Si l’attribut instance de la classe n’est pas défini et qu’il existe un constructeur sans paramètre, dodo utilise ce constructeur pour créer l’attribut instance de la classe lorsque celle-ci est chargée en mémoire. Par exemple:

class Maison
{
   Fenetre[] fenetres
   Couleur couleurMur, couleurToit
   make Maison()
   {
      .fenetres = [Fenetre()]
      .couleurMur = blanc
      .couleurToit = rouge
   }
}

Quand la classe Maison est chargée en mémoire, son attribut instance est initialisé en appelant le constructeur Maison() qui l’initialise avec une fenêtre, des murs blancs et un toit rouge.

Fonction fabrique

Une fonction fabrique d’objet est une fonction de classe qui renvoie un objet instance de cette classe en fonction de certains paramètres. Par convention, le nom d’une fonction fabrique d’objet commence avec new. Par exemple on pourrait définir une fonction Maison.newAvecMurEtToit(Couleur,Couleur).

Héritage

Une classe est elle-même un objet, qui utilise le modèle à base de prototype comme tout objet dodo. Une classe hérite d’une superclasse quand elle utilise cette superclasse comme prototype. La superclasse peut être une autre classe ou bien le type d’un objet.

La classe hérite des attributs, fonctions membres et autres propriétés de la superclasse. Le prototype des objets instance de la classe dérive du prototype utilisé (la superclasse est un objet) ou de l’attribut instance de la superclasse (la superclasse est une classe).

Une classe ne peut avoir qu’une seule superclasse, mais on peut lui appliquer plusieurs traits.

Trait

En plus de la notion de prototype et de classe, dodo a celle de trait (feature). Un trait s’applique à un objet ou à une classe pour lui définir des propriétés supplémentaires. Par exemple un nombre entier possède le trait Arithmetic qui lui apporte l’addition, la multiplication etc. ainsi que le trait Ordered (ordonné).

Un trait se définit de la même façon qu’une classe, mais il n’y a pas d’instance, de constructeur ou de fonction fabrique d’objet dans un trait.

Polymorphisme

Le polymorphisme permet de faire abstraction du type exact d’un objet pour n’en retenir que les propriétés générales. Un exemple typique de polymorphisme est une fonction qui attend un paramètre de type FormeGeometrique, où le paramètre peut être tour à tour un carré, un cercle, un trapèze…

Pour bénéficier du polymorphisme, le type de l’objet doit hériter de class ou de Object ou bien répondre au trait Polymorphic.

Conclusion

Pour un rapport complet du modèle objet de dodo il faudrait également évoquer les patrons (templates), les fonctions de conversion, les états abstraits et d’autres apports.
En l’état, on peut déjà voir toutes les possibilités qui s’ouvrent au programmeur sur la base d’un concept simple (le prototype) que le langage reprend sous diverses formes pour donner les outils familiers de la programmation orientée objet.