Un exercice simple pour débutant en ocaml c’est d’écrire un interpréteur pour un petit langage simple comme par exemple une calculatrice :

type arithmetic =
   | Cst of int
   | Neg of arithmetic
   | Add of binary
   | Sub of binary
   | Mul of binary
   | Div of binary
and binary =
   arithmetic * arithmetic

Mais cet exercice anodin change complètement de nature quand on passe à un langage fortement normalisant, dans ce cas vous devez aussi prouver que le programme se termine toujours et sans accident, quelles que soient les circonstances.

Cette preuve ce fait en deux étapes :

• d’abord il changer d’algèbre initiale
• ensuite il faut établir une égalité entre les deux types algébriques

Le changement d’algèbre initiale se fait en paraphrasant la déclaration du type, en remplaçant chaque occurrence de arithmetic par une occurrence de fold f :

let rec fold f = function
   | Cst n -> f#cst n 
   | Neg a -> f#neg (fold f a)
   | Add (a,b) -> f#add (fold f a) (fold f b)
   | Sub (a,b) -> f#sub (fold f a) (fold f b)
   | Mul (a,b) -> f#mul (fold f a) (fold f b)
   | Div (a,b) -> f#div (fold f a) (fold f b)

Le paramètre f est une égalité entre les deux types algébriques :

let id x = x   
   
let eval =
   fold (
      object
         method cst = id
         method neg = (~-)
         method add = ( + )
         method sub = ( - ) 
         method mul = ( * ) 
         method div = ( / )
      end )

À cette étape on est à l’abri des boucles infinies.
Mais on n’est pas à l’abri des interruptions intempestives, par exemple lors d’une division par zéro.

# eval (Div(Cst 1,Cst 0));;
Exception: Division_by_zero.

Dans les langages fortements normalisants les exceptions n’existent pas.
Pour simuler les exceptions on utilise la monade result pour propager le diagnostic d’erreur.

type ('a,'b) result =
   | Ok of 'a
   | Error of 'b 

let ok1 f v =
   match v with
   | Ok x -> Ok (f x)
   | Error _ -> v

let ok2 f v1 v2 =
   match v1,v2 with
   | Ok x1,Ok x2 -> Ok (f x1 x2) 
   | Error _, _ -> v1
   | _, Error _ -> v2

let result2 f v1 v2 =
   match v1,v2 with
   | Ok x1,Ok x2 -> f x1 x2 
   | Error _, _ -> v1
   | _, Error _ -> v2
   
let safe_division a b =  
   if b=0 then Error "Division_by_zero"
   else Ok (a/b)  

À l’aide de cette monade result on peut définir une nouvelle égalité qui prend en compte les possibilités d’erreur :

let ok n = Ok n   
      
let eval =
   fold (
      object
         method cst = ok
         method neg = ok1 (~-)
         method add = ok2 ( + )
         method sub = ok2 ( - ) 
         method mul = ok2 ( * ) 
         method div = result2 safe_division
      end )

Cette fois le programme suit son cours jusqu’au bout, sans interruption :

# eval (Div(Cst 1,Cst 0));;
- : (int, string) result = Error "Division_by_zero"      

Bien sûr un tel raffinement de style n’est pas forcément utile ou même désirable dans chaque code ocaml. Le langage étant multi-paradigmes par nature il vous invite à trouver le style qui vous convient le mieux.

Cependant, avec cette introduction courte et informelle sur les récurseurs et les monades, j’espère avoir donné quelques encouragements à ceux qui voudraient faire le grand saut vers un assistant de preuve.

– damien

Sylvain Le Gall et l’équipe organisatrice de la 3ième rencontre des programmeurs Objective-Caml vous donnent rendez-vous le 16 Avril à Paris.

Malheureusement je ne pourrai pas être présent cette année.

Hello,

For the third time, I am proud to invite all OCaml enthusiasts to join
us at OCaml Meeting 2010 in Paris.

This year event takes place in Paris on Friday 16th April 2010.
Subscription is opened and will be closed on Friday 2nd April 2010.

Presentations include:

• Enforcing Type-Safe Linking using Inter-Package Relationships for
  OCaml Debian packages
• The Ocamlviz visualization toolkit
• Cluster computing in Ocaml
• Ocaml in a web startup
• React, functional reactive programming for OCaml
• OASIS, a Cabal like system for OCaml
• OPA, same web, but with types and lambda
• OC4MC, Objective Caml for MultiCore
• Lwt, Cooperative Light-Weight Threads
• naclgrid: the collaborative rendering farm, a JoCaml-powered
  desktop grid

The meeting is sponsored by INRIA, the Caml Consortium and OCamlCore.
Inscription is free but the number of participants is limited.

Further information and inscriptions:

http://wiki.cocan.org/events/europe/ocamlmeetingparis2010

The day after OCaml Meeting, Mehdi Dogguy from PPS helps me to organize
an informal day where OCaml teams can meet to work. We will have 2
classrooms, each can host 45 persons. There will be an internet access
and a blackboard in each room. Inscription is free.

Further information and inscriptions:

http://wiki.cocan.org/events/europe/ocamlhackingday2010

Hope to see a lot of you,

Regards,

Sylvain Le Gall on behalf of the OCaml Meeting organization team.

Le tas binaire est un tableau qui implémente un arbre pseudo-complet vérifiant la propriété de tas.
Un tableau est de taille fixe. Par conséquent un tas binaire est borné, on ne peut y insérer qu’un nombre fixe et limité d’éléments. Bien sûr on pourrait redimensionner le tableau dynamiquement, mais cela a un impact négatif sur le coût des opérations.
Qu’on prêche le style impératif ou le style fonctionnel est étrangé à l’affaire.
La bonne question c’est de savoir si on connait d’avance le nombre d’éléments à insérer ou non.

Si on le connait alors un tas binaire fera très bien l’affaire.
Si on ne le connait pas, alors autant opter tout de suite pour un arbre binaire, même si on veut garder un style impératif.
Ça serait exactement la même problématique avec un dictionnaire. On peut faire une recherche dichotomique dans un tableau trié. Ou alors on peut faire une recherche dans un arbre ordonnée.
Dans les deux cas l’algorithme de recherche est le même, il s’agit dune boucle qui à chaque étape découpe l’espace de recherche en deux moitiés dont une seule peut contenir l’élément recherché.
Le paradigme a bien un impact sur le programmeur mais c’est parce que le programmeur est trop attaché à la syntaxe.
En réalité le paradigme impacte plus fortement la façon de faire que la façon de penser.
L’expérience aussi est un facteur qui impacte la façon de faire.
C’est pourquoi je préfère parler de style plutôt que de paradigme.

Le tas de Braun

Un petit rappel de quelques définitions :

• propriété de tas
• arbre complet
• arbre de Braun

On l’appelle tas de Braun parce que l’insertion répétée dans l’arbre vide produit un arbre de Braun.
Un autre nom est heap-ordered binary tree mais c’est moins spécifique.

type 'a heap = 

  | E (* 'a empty heap *) 

  | N of 'a non_empty_heap 

and 'a non_empty_heap = 

  {mutable l: 'a heap; mutable e: 'a; mutable r: 'a heap}

Remarques :

• on a un type tas non-vide, il n’y aura pas d’exceptions dans le code, la contrainte sur l’argument des fonctions find_max et remove_max sera exprimée par le type, la contrainte sur le résultat de insert également
• les champs sont mutables, c’est parce qu’on va utiliser le même type pour les deux styles de programmation, les algorithmes seront les mêmes, mais dans un cas on fera de la copie, dans l’autre on fera de la modification sur place

La fonction find_max est triviale :

Le style fonctionnel

On devrait dire le style immutable.
Je commence toujours par le style immutable parce que c’est plus lisible.
J’ai choisi un tas-max plutôt qu’un tas-min, pour un tas-min il n’y aura qu’à changer le signe où inverser le signe de la fonction compare.

let rec add x = function 

  | E -> 

      {l=E;e=x;r=E} 

  | N n ->  

      if compare n.e x > 0 then {l=N (add x n.r);e=n.e;r=n.l}  

      else {l=N (add n.e n.r);e=x;r=n.l} 

                    

let rec remove_max = function 

  | {l=E;r=t} | {r=E;l=t} -> 

      t 

  | {l=N l;e=e;r=N r} -> 

      if compare l.e r.e > 0 then N {l=remove_max l;e=l.e;r=N r} 

      else N {l=N l;e=r.e;r=remove_max r}

Le style impératif

On devrait dire le style mutable.
Je traduis à partir de la version en style immutable.

let rec insert x = function 

  | E -> 

      {l=E;e=x;r=E} 

  | N n -> 

      let nr = n.r in 

      n.r <- n.l; 

      if compare n.e x > 0 then n.l <- N (insert x nr) 

      else (n.l <- N (insert n.e nr); n.e <- x); 

      n 

                    

let rec delete_max h = 

  match h with  

  | {l=E;r=t} | {r=E;l=t} -> 

      t 

  | {l=N l;e=e;r=N r} -> 

      if compare l.e r.e > 0 then (h.e <- l.e; h.l <- delete_max l)  

      else (h.e <- r.e; h.r <- delete_max r); 

      N h

Autres opérations

Il faut mentionner qu’un tas de Braun offre des tas de possibilités de variantes et d’extensions qui seraient bien plus difficiles à implanter à l’aide d’un tas binaire.
Je ne vais pas être exhaustif sur ce point, je vais cependant en citer deux.
Il est également possible de supprimer un élément arbitraire dans un tas en le faissant percoler jusqu’à la racine puis en invoquant remove_max.

La fusion

Il est possible de fusionner deux tas de Braun en un seul tas.

let rec join ha hb = 

  match ha,hb with 

  | t,E | E,t -> 

      t 

  | N a,N b -> 

      if compare a.e b.e > 0 then N {l=join a.l a.r;e=a.e;r=hb} 

      else N {l=ha;e=b.e;r=join b.l b.r}

On peut accélérer l’opération de fusion à l’aide d’une technique dite de « structural bootstrapping ».
Grâce à cette technique il est possible de fusionner deux tas simplement en insérant l’un dans l’autre.

L’arbre tournoi

On peut modifier légèrement les opérations d’insertion et de suppression pour que le tas restitue l’ordre d’insertion quand on le parcourre dans l’ordre infixe.
Toutefois cette modification a un impact sur la performance, le tas n’est plus pseudo-complet comme un arbre de Braun.

Typiquement on insère les scores dans l’arbre tournoi, le gagnant est toujours à la racine.
Le parcourt infixe restitue la liste des scores dans l’ordre d’apparition des joueurs.

let rec add x = function 

  | E -> 

      {l=E;e=x;r=E} 

  | N n ->  

      if compare n.e x > 0 then {n with r=N (add x n.r)}  

      else {l=N n;e=x;r=E} 

                    

let rec remove_max = function 

  | {l=E;r=t} | {r=E;l=t} -> 

      t 

  | {l=N l;e=e;r=N r} as t -> 

      if compare l.e r.e > 0 then 

        N{l=l.l;e=l.e;r=remove_max {t with l=l.r}} 

      else 

        N{l=remove_max {t with r=r.l};e=r.e;r=r.r}

Conclusion

La chose à retenir c’est que ce n’est pas le fonctionnel qui force à changer de structure de données.
Ce qui force à changer de structure de données c’est le fait qu’un tableau n’est pas toujours la meilleure option. Utiliser une liste ou un arbre au lieu d’un tableau n’interdit pas le style mutable.
Il n’y a pas un paradigme impératif qui s’oppose à un paradigme impératif fonctionnel, il y a juste le style mutable et le style immutable qui sont deux façons d’implanter un même algorithme pour une même structure de données.
On peut d’ailleurs très bien adopter le style immutable avec un langage à objets si le ramasse-miettes est suffisamment efficace pour ça.

Un MIME (Multipurpose Internet Mail Extension) est une information système pour identifier les types de fichier et leur affecter certains attributs comme une commande par défaut ou une icône personnalisée.

Ce billet vous propose d’agrémenter votre station de développement Objective-Caml à l’aide d’un MIME pour vos fichiers source.
Bien sûr ça n’est qu’un exemple que vous pourrez adapter à votre application ou à votre langage de programmation favori.

D’abord un avertissement :

• l’ajout de MIMEs est une opération potentiellement dangereuse, en effet si vous perdez tous vos MIMEs vous ne pourrez plus monter un volume en cliquant sur son icône et vous devrez retourner à la console pour réaliser la plupart des opérations mêmes les plus élémentaires
• tapez la commande update-mime-database /usr/share/mime dans une console
• si cette commande n’est pas reconnue alors votre système ne gère pas la mise à jour des MIMEs et vous devrez opérer à la main, à condition de savoir ce que vous faites

Sinon créez un fichier /usr/share/mime/packages/ocaml.xml et éditez-le avec ce contenu :

Puis exécutez la commande update-mime-database /usr/share/mime.

Vous pouvez alors définir tous les paramètres liés à un MIME comme une icône personnalisée et une action par défaut pour votre gestionnaire de fichiers.

Par exemple définir une icône personnalisée pour ROX-filer :

• sauvez le fichier image en tête de cet article
• sélectionnez le menu File/Set Icon… sur un fichier *.ml
• cochez la case Pour tous les fichiers de type ‘text/ocaml-source
• lâchez l’image sur la zone réservée à cet effet

Le billet d’aujourd’hui a pour but de faire toute la lumière sur la qualification à l’intérieur des modules Objective-Caml.

Un module paramétré est un module-fonction, c’est-à-dire une fonction d’un module-type vers un module-type qui accepte un module-valeur pour argument réel.

La définition d’un module paramétré conduit fréquemment à ce genre de code où Graphics est l’argument formel du module-fonction Draw.

module type Graphics
  =
  sig
    type color = Black | White
    type point = {x:int;y:int}
    val draw_line : int -> int -> int -> int -> unit
  end

module Draw (G: Graphics)
  =
  struct
    let pen = Black
    let background = White
    let connect a b = G.draw_line a.x a.y b.x b.y 
  end

Au premier abord il est surprenant qu’OCaml n’accepte pas ce code.
Il ne l’accepte pas pour deux raisons similaires :

• les couleurs Black et White ne sont pas définies dans le module Draw
• les champs x et y ne sont pas définis dans le module Draw

Le contournement évident consiste à tout qualifier par le module G.

module Draw (G: Graphics)
  =
  struct
    let pen = G.Black
    let background = G.White
    let connect a b = G.draw_line a.G.x a.G.y b.G.x b.G.y 
  end

Une fois tout qualifié par le module G ocaml accepte le code.
Mais cette solution peut vite devenir assez lourde.
Il y a d’autres moyens pour soulager la notation.

Un moyen classique consiste à ouvrir le module G de façon à accéder à ses définitions sans avoir à qualifier systématiquement.

module Draw (G: Graphics)
  =
  struct
    open G
    let pen = Black
    let background = White
    let connect a b = draw_line a.x a.y b.x b.y 
  end

Toutefois un reproche que l’on peut faire à l’ouverture de module c’est qu’on ouvre tout ou rien. Il n’est pas possible, à l’aide d’open, d’ouvrir le type G.point parce que les champs G.x et G.y impactent beaucoup la lisibilité mais de laisser le type G.color fermé parce que G.Black et G.White ne sont pas très gênants.
Ça n’est pas possible à l’aide d’open mais ça l’est à l’aide d’une égalité de types.
L’idée c’est de déclarer un type point équivalent au type G.point.
Ce type local agira comme un alias pour le type G.point.
De cette façon le module G reste fermé mais on peut accéder directement aux composantes x et y sans les qualifier.

module Draw (G: Graphics)
  =
  struct
    type point = G.point = {x:int;y:int}
    let pen = G.Black
    let background = G.White
    let connect a b = G.draw_line a.x a.y b.x b.y 
  end

En allant jusqu’au bout de cette logique on peut carrément inclure le module G, dans ce cas le module Draw contient une copie complète du module G et il n’y a plus rien à qualifier.

module Draw (G: Graphics)
  =
  struct
    include G
    let pen = Black
    let background = White
    let connect a b = draw_line a.x a.y b.x b.y 
  end

Attention toutefois à ne pas abuser du include là où un open ferait très bien l’affaire.
Le include ajoute tout le module à l’interface du module en cours.
Il a donc un effet à l’extérieur du module alors que l’effet de open est limité à l’intérieur.
N’utilisez include que si c’est nécessaire pour implanter l’interface voulue, si vous n’avez que besoin d’alléger la qualification dans l’implantation alors c’est open qu’il vous faut.

Hier, afin d’illustrer l’usage de LablGtk2, le binding GTK+ pour le langage Objective-Caml j’ai posté le code de ce Hello Developpez tout ce qu’il y a de plus basique :

Toutefois, une comparaison ligne à ligne avec la version Gtk2Hs pour Haskell, grâcieusement postée par Alp, n’était pas possible puisque mon code n’utilisait pas libglade.

On pourrait se demander pour quelle raison utiliser libglade car OCaml est un langage statiquement typé particulièrement sûr comparé à un fichier XML chargé dynamiquement et qui pourrait être modifié sans contrôle à tout moment. On pourrait argumenter qu’il est bon de séparer le visuel de l’interface et sa logique interne mais là encore le système de modules de OCaml est particulièrement bien adapté pour le separation of concerns.
L’intérêt indiscutable c’est la flexibilité, en particulier l’internationalisation est bien plus facile à réaliser que si elle était codée en dur. Et puis après tout la question n’est pas là, c’est à la mode, on peut le faire en Haskell, on peut le faire en OCaml, c’est facile à faire et ça justifie bien un nouveau billet blog.

Mon fichier XML est en tous points identique à celui de Alp :

Faites attention à ce que la balise ?xml soit bien sur la toute 1ière ligne du fichier sinon OCaml génèrera un avertissement et/ou une exception.

Le code source OCaml pour charger le XML et quitter quand l’utilisateur clique sur le bouton :

let xml =
   Glade.create ~file:"hello.glade" ()
in let window = new GWindow.window
   (GtkWindow.Window.cast(Glade.get_widget xml "window1"))
in let button = new GButton.button
   (GtkButton.Button.cast(Glade.get_widget xml "yo")
in button#connect#clicked ~callback:
   (fun () -> print_endline "Bye"; window#destroy (); GMain.Main.quit ());
   window#show ();
   GMain.Main.main ()

La différence principale avec Gtk2Hs, hormis l’absence de la do-notation, se situe au niveau du chargement et de la conversion.
C’est légèrement plus tortueux qu’en Gtk2Hs, ça se fait en 3 étapes. C’est dû à la couche orienté-objet de LablGtk.

1. on charge le gadget à l’aide de Glade.get_widget, on obtient un Gtk.widget Gtk.obj
2. on converti ce Gtk.widget Gtk.obj en Gtk.window Gtk.obj à l’aide de GtkWindow.Window.cast
3. ça ne s’arrête pas là, il n’est toujours pas possible d’utiliser cette fenêtre avec les méthodes de LablGtk parce qu’un Gtk.window Gtk.obj est une valeur mais pas un objet. il faut une deuxième conversion en un objet GWindow.window, en fait une instanciation réalisée par new GWindow.window

Voilà, ça n’était pas sorcier mais comme il faut naviguer dans une doc hyper-texte touffue et avare en explication, la première fois c’est toujours un peu déroutant.

Motifs variable

Comme vous le savez sans doute le let ne permet pas seulement de déclarer une nouvelle variable par exemple ici la variable m :

  let choose = function
    | None -> None
    | Some n -> let m = minimum n n.left in Some (m.key,m.item)

Motifs simples

Il permet aussi de déconstruire une valeur selon un motif comme ici la paire (m,l) :

  let rec delete_min t = 
    match t.left with
    | None   -> t,t.right
    | Some n -> let m,l = delete_min n in m,Some {t with left = l}

Bien sûr le let n’accepte qu’un motif qui ne doit pas pouvoir échouer (on dit aussi exhaustif).
Dans le cas contraire OCaml génère un avertissement et vous seriez bien avisé d’utiliser un match afin de gérer tous les cas.
La déconstruction par une variable m réussi toujours puisqu’une variable est un motif universel (la variable _ n’a rien de plus universel, elle est seulement plus anonyme).
La déconstruction par un couple de variables (m,l) réussi toujours également puisqu’une paire ne peut pas être autre chose qu’un couple de valeurs.

Là où le let ne fait plus l’affaire c’est sur un type union comme celui-ci :

type ast_val =
  | Val of int            (* offset *)
  | Array of int * int    (* offset, size of item *)

Qui dit qu’une valeur est :

• ou bien une valeur positionnée à un certain offset
• ou bien un tableau de valeurs (de même taille) positionné à un certain offset

Dans le cas général, on utilise un match pour déconstruire les valeurs union.
Cependant, il arrive qu’un traitement ne dépende pas du constructeur mais d’une information disponible dans tous les cas.

Par exemple ici on génère du code qui va placer l’adresse d’une certaine valeur dans un certain registre cpu :

  let rec eval_addr reg = function
    | Member(record,var) -> 
        eval_addr reg record;
        ( match var with
        | Var offset ->
            emit (Addr(reg,Offset(reg,offset)))
        | Array(offset,_) ->
            emit (Addr(reg,Offset(reg,offset))) )
    | ItemAt(vector,index,size) ->  
        eval_addr reg vector;
        eval_val (reg+1) index;
        emit (Addr(reg,Scale(reg,reg+1,size)))

Le code émit ne dépend que de l’offset, il est le même que la valeur soit un tableau ou non.
Distinguer les deux cas devient alors une nuisance, il y a répétition et de plus il faut parenthéser le match pour qu’il ne capture pas le cas ItemAt(vector,index,size). On peut faire plus agréable à l’oeil.

Motifs union

L’union d’un motif a et d’un motif b est un motif noté a | b qui accepte aussi bien le motif a que le motif b. (¹)
Dans notre code on peut éviter la répétition en utilisant un motif union :

  ( match var with
  | Var offset | Array(offset,_) ->
      emit (Addr(reg,Offset(reg,offset))) )

En fait, puisqu’on n’a qu’un seul motif exhaustif qui sert essentiellement à déclarer la variable offset, on peut carrément remplacer match par un let :

  let Var offset | Array(offset,_) = var
  in  emit (Addr(reg,Offset(reg,offset)))

(¹) il y a quelques contraintes sur les motifs a et b, ils doivent être de même type et déclarer le même ensemble de variables

À la lecture de The Art of the Propagator je me suis laissé convaincre que l’avenir de la programmation déclarative était dans la propagation logique. L’intérêt de la propagation c’est que le calcul monodirectionnel disparaît, le calcul devient multi-directionnel, la béta-réduction devient la béta-équivalence.

Jusqu’à présent je m’étais toujours dit « et alors, quel intérêt ? ».
C’est là que The Art of the Propagator apporte un argument de poids :

• le calcul monodirectionnel suppose un temps fondamentalement linéaire, il y a un avant et un après la réduction
• le parallélisme c’est quand le temps n’est plus linéaire
• pourquoi chercher à recréer l’illusion du temps linéaire alors qu’il suffit de lever la restriction monodirectionnelle pour adopter le point de vue du parallélisme ?

Ni une ni deux, installation presto de B-Prolog et petite traduction de l’exemple tiré de The Art of the Propagator (le document d’origine utilise des composants logiciels en Scheme à connecter comme pour une simulation de circuit électronique) :

temperature(F,C,K) :-
   C is (F - 32) * 5/9,
   K is C + 273.

J’adore ce style complètement équationnel.

Ce code peut convertir en degrés celsius et degrés en kelvins et même détecter une contradiction entre deux valeurs non convertibles :

| ?- temperature(77,C,K).
C = 25.0
K = 298.0
yes
| ?- temperature(45,C,298).
no

Malheureusement il semblerait que le calcul soit monodirectionnel, tout se passe comme si C était calculé à partir de F puis K à partir de C. Il m’est imposible d’obtenir une réponse sans fournir une valeur pour F :

| ?- temperature(F,25,K).
***  error(instantiation_error,b_EVAL_ARITH_cf/2)
| ?- temperature(F,C,298).
***  error(instantiation_error,b_EVAL_ARITH_cf/2)

Il y a sans doute une façon de le faire en Prolog mais j’aurai aussi vite fait de l’écrire en Caml.

Les circuits sont composés de constantes entières, de variables (réliées à un ou deux composants), d’entrées (limitées à 2), de sorties et d’opérateurs :

type expr =
  | Int of int
  | Var1 of int * expr
  | Var2 of int * expr * expr
  | Input1 of operator
  | Input2 of operator
  | Output of operator 
and operator =
  <input1:evaluator; input2:evaluator; output:evaluator>
  * expr * expr * expr
and evaluator =
  (expr -> int option) -> expr -> expr -> int option 

L’évaluateur eval calcule la valeur d’un point du circuit.
Le paramètre m est un marqueur destiné à éviter les parcours en boucle.
Etant donné l’environnement env, il suffira d’appeler l’évaluateur sur un noeud contenant une variable pour connaître sa valeur.

Cette façon de faire me paraît plus dénotationnelle que la version Scheme de The Art of the Propagator qui donne une sémantique opérationnelle à l’aide d’un scheduler.

Remarquez que du fait que mon circuit est paramétré par un environnement j’obtiens gratuitement un moyen d’abstraction sur les circuits propagateurs. Je n’aurai qu’à créer un nouvel environnement pour changer les 3 températures alors qu’avec la version Scheme il faut explicitement reconnecter un nouveau circuit (les températures sont immutables).

let rec eval env m = function
  | Var1(n,e1) ->
      ( match List.nth env n,eval env m e1 with
      | None,x | x,None -> x
      | Some x,Some y when x = y -> Some x
      | _ -> failwith "incoherence" )
  | Var2(n,e1,e2) ->
      ( match List.nth env n,eval env m e1,eval env m e2 with
      | x,None,None | None,x,None | None,None,x -> x
      | None,Some y,Some z when y = z -> Some z
      | Some x,None,Some z when x = z -> Some x
      | Some x,Some y,None when x = y -> Some y
      | Some x,Some y,Some z when x = y && y = z -> Some z
      | _ -> failwith "incoherence" )
  | Int n ->
      Some n
  | Input1 p ->
      if p == m then None else 
      let op,a,b,c = p in op#input1 (eval env p) b c
  | Input2 p ->
      if p == m then None else 
      let op,a,b,c = p in op#input2 (eval env p) a c
  | Output p ->
      if p == m then None else 
      let op,a,b,c = p in op#output (eval env p) a b

La classe operation nous permettra d’ajouter facilement des opérateurs.

class operation fa fb fc =
  let result f x y =
    match x,y with
    | Some x,Some y -> Some(f x y)
    | _ -> None
  in
  object
    method input1 : evaluator =
      fun eval b c -> result fa (eval c) (eval b)
    method input2 : evaluator = 
      fun eval a c -> result fb (eval c) (eval a)
    method output : evaluator = 
      fun eval a b -> result fc (eval a) (eval b)  
  end

Trois opérateurs élémentaires:

let add = new operation ( - ) ( - ) ( + )
and mul = new operation ( / ) ( / ) ( * ) 
and sub = new operation ( + ) (fun c a -> a - c) ( - ) 

La construction du circuit :

let t =
  let
  rec f = Var1(0,Output add32)
  and c = Var2(1,Input2 mul9,Input2 add273)
  and k = Var1(2,Output add273)
  and add32  = add, Int 32, Input2 mul5, f
  and mul5   = mul, Int 5, Input2 add32, Output mul9
  and mul9   = mul, Int 9, c, Output mul5
  and add273 = add, Int 273, c, k
  in
  object
    method fahrenheit = f
    method celsius = c
    method kelvin = k
  end

L’objet renvoyé en résultat fourni un accès direct aux trois sondes de température du circuit.

Une rédéfinition de eval pour démarrer avec un marqueur fantôche :

let eval env expr =
  let start = add,Int 0,Int 0,Int 0
  in  eval env start expr

Des exemples d’inférence :

# eval [None;Some 25;None]  t#fahrenheit;;
- : int option = Some 77
# eval [Some 77;None;None]  t#celsius;;
- : int option = Some 25
# eval [Some 77;None;None]  t#kelvin;;
- : int option = Some 298
# eval [None;None;Some 298] t#fahrenheit;;
- : int option = Some 77

Cohérence et incohérence de valeurs multiples :

# eval [None;Some 25;Some 298] t#fahrenheit;;
- : int option = Some 77
# eval [None;Some 23;Some 298] t#fahrenheit;;
Exception: Failure "incoherence".

En ajoutant un peu de sucre syntaxique il devrait être possible de déclarer temperature comme en Prolog.

Avec le code de eval on a déjà l’élément de base pour écrire un interpréteur pour un langage déclaratif multi-directionnel.
Cependant on irait pas très loin car The Art of the Propagator ne dit pas comment exploiter la multi-directionnalité sur des exemples plus convaincants. Peut-on par exemple exécuter un dérivateur formel « à l’envers » pour obtenir un intégrateur formel par propagation ?
Si oui, comment ? Si non, pourquoi ?

Au bout du compte la thèse est avare en exemples consistants et se contente de conjecturer de possibles champs d’application, notamment dans les domaines des TMS (Truth aintenance Systems), de la recherche dirigée par les dépendances et la FRP (Functional reactive Programming).

Dans mon petit exemple de ce jour on va utiliser l’application partielle pour faire l’inverse de ce qu’on en fait habituellement. Au lieu d’éliminer un argument on va au contraire en ajouter un supplémentaire.

L’idée de départ c’est que, étant donné un opérateur diadic (supposé associatif à droite), nous l’appliquons deux fois pour pouvoir opérer sur 3 arguments:

let triadic op a b c = op a (op b c);; 

Une application partielle sert à produire un nouvel opérateur triadic:

let plus_plus = triadic (+);; 

Comme on a appliqué un argument, la fonction plus_plus ne prend plus que 3 arguments au lieu de 4 pour la fonction triadic.

C’est un point de vue, en tout cas c’est celui mis en avant dans nombre d’introductions à la programmation fonctionnelle.

Un autre point de vue, sans doute plus approprié ici, c’est que la fonction plus_plus prend 3 arguments au lieu de 2 pour la fonction (+) :

plus_plus 1 2 3;;  
- : int = 6

Encore plus fort!
Plus d’arguments mais cette fois-ci sans application partielle!

Vous conviendrez aisément que cette fonction ne prend qu’un seul argument:

let id x = x 

Hé bien je peux, mesdames et messieurs, devant vos yeux ébahis, lui appliquer 4 arguments:

# id id (+) 1 2;;
- : int = 3

Et c’est bien typé!
Incroyable, ils sont fous ces programmeurs fonctionnels!