Si vous ne l’avez pas déjà fait dépêchez-vous de visionner ou de télécharger
la vidéo conférence de Heinrich Apfelmus sur les GADTs (Generalized Algebraic Data Types).

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

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.

Dans ce billet je vais encore plus loin en vous proposant directement un panel d’icônes taillées sur mesure pour le gestionnaire de fichiers ROX-Filer.

Bien sûr si vous semblez frappé d’injustice du fait que votre langage de programmation favori ne soit pas représenté, vous pouvez me faire une proposition que j’ajouterai pour élargir la gamme de fichiers sources personnalisables.

Ce n’est pas la première fois que je vous parle de jeu-vidéo et de programmation fonctionnelle.
Cette fois il s’agit de Raincat, un jeu SDL écrit en Haskell, pour Windows et Linux.

Le jeu consiste à déposer les accessoires (dans la colonne à droite) sur le parcours du chaton afin que celui-ci atteigne la sortie du niveau malgré la pluie et diverses projections d’eau. Car le Raincat est réellement hydrophobe, la moindre goutte sur son pelage délicat et vous devrez recommencer le niveau.

À vrai dire ce petit puzzle ne m’a pas rendu accro. Maintenir un chaton propre et toujours au sec m’apparaît difficilement comme un enjeu ludique motivant.

Ce qui est peut être plus intéressant que le jeu en lui-même c’est le témoignage que le fossé qui séparaient les langages académiques des applications quotidiennes se comble de jours en jours.

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.

Définition

C’est comme pour un langage à objets, étant un paradigme riche il y a plusieurs définitions possibles pour un langage fonctionnel.

Une définition possible: c’est un langage qui offre les fermetures (une fonction liée à un environnement d’évaluation).
Avantage de cette définition: elle est tolérante.
Inconvénient de cette définition: elle perd de sa pertinence au fur et à mesure que la plupart des langages à objets intègrent plus ou moins cette fonctionnalité.

Une autre définition possible: c’est un langage avec un sytème de typage riche, riche au point qu’il devienne insupportable de ne pas être assisté par une forme d’inférence de type.
Avantage: c’est plus représentatif de la spécificité des langages fonctionnels modernes.
Inconvénient: ça exclut les assembleurs de langages (macro-langages) que sont les vénérables Lisp et Scheme.

Autres définitions (plus techniques et plus ou moins équivalentes entre elles) :

• c’est un langage inspiré du lambda calcul
• c’est un langage inspiré des catégories bi-cartésiennes fermées
• c’est un langage où Hom(A × B, C) = Hom(A, Hom(B,C))

Utilisation

Typiquement les macro-langages font des merveilles pour prototyper la conception de nouveaux paradigmes (réflection, AOP et autre POO étendue ou exotique).
Typiquement les langages à inférence de type font des merveilles pour implémenter les spécification algébriques et les algorithmes avancés.

Historiquement les langages à inférence de type sont très liés à la preuve de programme, ce qui les rends très lisibles dès lors qu’on est familier avec leurs concepts exotiques (du point de vue d’un programmeur POO) et la syntaxe particulière qui va avec.
Mais aujourd’hui la programmation fonctionnelle s’est élargie et démocratisée et on peut quasiment tout faire avec, y compris des jeux SDL, Allegro ou SFML, de la 3D OpenGL, de la programmation système, du web et bien d’autres choses encore.

Avenir académique

Au niveau académique la programmation par objets n’est plus un domaine vraiment actif, pour plusieurs raisons :

• la recherche sur la POO avait beaucoup exploré toutes sortes de variantes exotiques de la sémantique de l’envoi de messages, en pratique aucune variante n’a été assez convaincante pour éclipser le fait que le modèle d’exécution de C++ est le plus performant
• il est plus fructueux d’associer une extension objets à un langage fonctionnel que le contraire
• même si en lui-même le paradigme fonctionnel n’apporte pas la solution à la question du parallélisme, au moins il repose sur un modèle théorique plus simple qui permet de se concentrer sur le coeur de la difficulté
• le modèle du lambda-calcul est tellement simple qu’il se prête à d’infinies variantes / extensions, potentiellement porteuses de nouveaux paradigmes (voir Bondi par exemple), éventuellement ces expérimentations connaîtront le même sort que les expérimentations sur l’envoi de message mais il est trop tôt pour l’affirmer aujourd’hui

Avenir industriel

La programmation fonctionnelle a déjà réussi dans le sens où la plupart des langages à objets sont dotés (ou envisagent de se doter) d’une extension offrant les fermetures. Cependant l’influence de la programmation fonctionnelle va déjà bien au delà et les nouveaux langages à objets (Scala,F#,Clojure,Groovy,Go) sont ouvertement influencés par les langages fonctionnels. L’industrie a plébiscité l’objet et continuera de le faire mais d’une façon moins dogmatique qui ouvre la voie aux approches mixtes objet / fonctionnel.

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.