L'autre nuit, muni de café, j'ai souhaité m'amuser avec Haskell. J'ai alors consulté le chapitre sur le réseau en Haskell de Real World Haskell et... j'ai écrit un (très petit) clône de client telnet... qui fait 41 lignes. Le seul soucis étant que dans toute application de ce genre, on doit partager habilement la lecture des entrées de l'utilisateur, et l'affichage de ce que l'on nous envoie. Ceci mis à part, tout cela fonctionne très bien !

Regardons à quoi cela ressemble. Petit détail : à chaque tour, je lance la réception de données réseau dans un autre thread, pour ne pas bloquer l'écriture de l'utilisateur.

On importe d'abord les modules nécessaires.

import Control.Concurrent 
import Control.Monad 
import Network.Socket 
import Network.BSD 
import System.Environment 
import System.IO

Ensuite, j'ai écrit quelques fonctions pour rendre la connection, l'envoi etc plus faciles.

-- Ouverture d'une connexion TCP cliente 
-- Prend en argument l'host et le port/service (qui est une String également) 
-- Retourne le "Handle" vers le socket en question. 
openConnection :: String -> ServiceName -> IO Handle 
openConnection hostname port = 
  do 
  addrInfos <- getAddrInfo Nothing (Just hostname) (Just port) 
  let serveraddr = head addrInfos 
  sock <- socket (addrFamily serveraddr) Stream defaultProtocol 
  setSocketOption sock KeepAlive 1 
  connect sock (addrAddress serveraddr) 
  h <- socketToHandle sock ReadWriteMode 
  hSetBuffering h (BlockBuffering Nothing) 
  return h 
 
-- Ferme la connexion dont le Handle est donné 
closeConnection :: Handle -> IO () 
closeConnection h = hClose h 
 
-- Envoie la chaîne donnée sur le Handle donné, et ensuite fait un flush sur ce handle, ce qui force l'envoi immédiat et nettoie les états 
sendMsg :: Handle -> String -> IO () 
sendMsg h msg = hPutStrLn h msg >> hFlush h 
 
-- Lis sur le Handle donné une chaîne et la renvoie (dans la monade IO) 
recvMsg :: Handle -> IO String 
recvMsg h = do 
  msg <- hGetContents h  
  return msg

Voyons maintenant la fonction main.

main = do 
  args <- getArgs 
  let (host, port) = (args !! 0, args !! 1)

On récupère les arguments donnés au programme (s'il n'y en a pas assez, cela fera planter le logiciel -- je ne me suis pas vraiment préoccupé de tous les cas d'erreur, mais ce n'était pas ma priorité ici) via la fonction getArgs, et l'on en récupère l'host et le port donnés.

  putStrLn $ "Opening client on " ++ host ++ ":" ++ port ++ "\n" 
  hclient <- openConnection host port 
  putStrLn "Client connected"

Ca y est, on se connecte, en affichant des messages pour tenir l'utilisateur informé. Si la connection échoue, le programme s'arrêtera avec une erreur -- cf remarque ci-dessus.

Et maintenant, la boucle qui permet de lire depuis le réseau et lire depuis l'utilisateur, etc.

  forever $ do 
    getLine >>= sendMsg hclient 
    forkIO $ recvMsg hclient >>= putStrLn

Ici, on a une sorte de boucle "à la while(true)", dans laquelle on va tour à tour récupérer une entrée de l'utilisateur et l'envoyer au serveur, puis, dans un thread séparé, récupérer ce qu'a envoyé le serveur et l'afficher.
Enfin, on ferme la connection (ce code est inutile tant que l'on a pas de possibilité de sortir du forever... qui devra tôt ou tard se transformer en "until" ou autre).

  closeConnection hclient

Voilà le code complet :

import Control.Concurrent 
import Control.Monad 
import Network.Socket 
import Network.BSD 
import System.Environment 
import System.IO 
 
openConnection :: String -> ServiceName -> IO Handle 
openConnection hostname port = do 
  addrInfos <- getAddrInfo Nothing (Just hostname) (Just port) 
  let serveraddr = head addrInfos 
  sock <- socket (addrFamily serveraddr) Stream defaultProtocol 
  setSocketOption sock KeepAlive 1 
  connect sock (addrAddress serveraddr) 
  h <- socketToHandle sock ReadWriteMode 
  hSetBuffering h (BlockBuffering Nothing) 
  return h 
 
closeConnection :: Handle -> IO () 
closeConnection h = hClose h 
 
sendMsg :: Handle -> String -> IO () 
sendMsg h msg = hPutStrLn h msg >> hFlush h 
 
recvMsg :: Handle -> IO String 
recvMsg h = do 
  msg <- hGetContents h  
  return msg 
 
main = do 
  args <- getArgs 
  let (host, port) = (args !! 0, args !! 1) 
  putStrLn $ "Opening client on " ++ host ++ ":" ++ port ++ "\n" 
  hclient <- openConnection host port 
  putStrLn "Client connected" 
  forever $ do 
    getLine >>= sendMsg hclient 
    forkIO $ recvMsg hclient >>= putStrLn 
  closeConnection hclient

Compilation :

ghc --make -o net net.hs

Puis 2 exemples d'exécution...

$ ./net google.fr 80
Opening client on google.fr:80
Client connected
GET / HTTP/1.0
HTTP/1.0 302 Found
Location: http://www.google.fr/
Cache-Control: private
Content-Type: text/html; charset=UTF-8
Set-Cookie: PREF=ID=30b094ad566b5532:TM=1251456529:LM=1251456529:S=94IXp5-SGiaYADWc; expires=Sun, 28-Aug-2011 10:48:49 GMT; path=/; domain=.google.com
Date: Fri, 28 Aug 2009 10:48:49 GMT
Server: gws
Content-Length: 218 



302 Moved
The document has moved
here.
 

^C

(c'est moi qui ai tapé "GET / HTTP/1.0")
( qui vous dira que la page a été déplacée )

Et enfin, la surprise...

$ ./net towel.blinkenlights.nl 23

Qui, une version simplifiée d'un film très connu, vous permettra de voir, Jedi.

Enjoy !

Cela fait quelques temps maintenant que la communauté Haskell a sorti Haskell Platform. Il s'agit d'un "paquet" qui regroupe :
- le compilateur haskell GHC, un debugger, un profiler, etc
- les bibliothèques les plus populaires et les plus utilisées, fournies d'office
- tout un tas d'outils auxiliaires, comme haddock, qui permet de générer de la documentation depuis les commentaires du code source.

Il existe des paquets pour déjà quelques distributions Linux, sachant que ce sera bientôt prêt pour Debian et Ubuntu également. Les installeurs Windows et Mac sont très simples également.

Bref, plus aucune raison de ne pas essayer Haskell

M'étant mis à Haskell depuis quelques temps (principalement grâce au désormais fameux Real World Haskell), je me suis dis qu'il était temps que je regarde un peu du côté des bibliothèques pour interfaces utilisateurs. Hé bien, je n'ai pas été déçu. Il y a notamment Gtk2Hs qui fournit un bon binding de GTK+, compatible avec Glade (le designer) et qui permet donc de charger des interfaces depuis du XML.

Allez-y, devinez combien de lignes il a fallu ?
Initialiser le GUI, créer les widgets, ... Hmm beaucoup ?

Hé bien non ! Le designer, Glade, exporte le "projet" suivant dans un XML.

XML généré :

<?xml version="1.0"?> 
<glade-interface> 
  <!-- interface-requires gtk+ 2.16 --> 
  <!-- interface-naming-policy project-wide --> 
  <widget class="GtkWindow" id="window1"> 
  <property name="title" translatable="yes">Hello, Developpez !</property> 
  <property name="default_width">400</property> 
  <property name="default_height">400</property> 
  <child> 
  <widget class="GtkButton" id="yo"> 
  <property name="label" translatable="yes">Bonjour Developpez, comment vas-tu ? 
 
Je suis un programme Haskell qui utilise 
Gtk2Hs, binding Haskell de GTK+. 
 
Clique pour fermer.</property> 
  <property name="visible">True</property> 
  <property name="can_focus">True</property> 
  <property name="receives_default">True</property> 
  </widget> 
  </child> 
  </widget> 
</glade-interface>

Et voilà, l'essentiel est fait.

Voici donc le main.hs, qui est le programme Haskell dont vous avez vu un screenshot plus haut :

module Main where 
 
import Graphics.UI.Gtk -- on importe le module GTK 
import Graphics.UI.Gtk.Glade -- et le module Glade, pour créer une IHM depuis le XML au format Glade 
 
main = do 
  initGUI 
  Just xml <- xmlNew "test.glade"  
  window <- xmlGetWidget xml castToWindow "window1" 
  button <- xmlGetWidget xml castToButton "yo" 
  onClicked button $ do 
  putStrLn "Bye" 
  mainQuit 
  onDestroy window mainQuit 
  widgetShowAll window 
  mainGUI

Et voilà. Assez simple non ?

Il y a peu, on m'a demandé d'écrire un programme qui récupère un flux Atom XML et qui ne récupère que le titre et l'url des éléments (qui en l'occurence sont des billets aggrégés sur Planet OCaml).

J'ai hésité entre OCaml, C++ et Haskell. Plutôt tenté par du fonctionnel, mon choix s'est vite porté sur Haskell grâce au nombre impressionnant de paquets présents sur Hackage.
J'ai donc opté pour le paquet feed pour la gestion d'Atom et download pour la récupération du XML distant, qui se situe ici).

Haskell Logo

Alors, voyons voir... Premièrement, on importe les modules dont on a besoin, évidemment.

import Network.Download
import Text.Atom.Feed
import Text.Feed.Import
import Text.Feed.Types

Ensuite, on définit l'adresse du fichier atom.xml... Toujours rien de bien sorcier.

url = "http://planet.ocamlcore.org/atom.xml"

Puis on se lance dans main !

main = do
    putStrLn "*** Recent blog posts ***"
    Right src <- openURIString url

Ici, on affiche simplement un message dans la console, puis on récupère le contenu du fichier dans la chaîne de caractères src.
Right est l'un des constructeurs du type Either, ne vous en préoccupez pas trop.

Ensuite, on s'occupe à proprement parler du flux Atom...

let Just (AtomFeed is) = parseFeedString src

Just est un constructeur du type Maybe, qui permet de gérer les erreurs (Just mavaleur si pas eu d'erreur, Nothing si une erreur). AtomFeed est lui un constructeur pour le type Feed précisant que c'est un flux Atom, et non RSS1 ou RSS2 par exemple (qui sont eux aussi gérés par ce même paquet). La fonction parseFeedString prend donc une chaîne (ici src) et retourne un flux Atom... C'est là, en utilisant is, que l'on va pouvoir récupérer les différents éléments du XML au format Atom.

Bon, et si on récupérait les différentes entrées de notre flux (ici ce sont des billets de blog) ?

let entries = feedEntries is

Ceci nous retourne donc une liste d'Entry. Et c'est parti, on va récupérer les informations qu'il nous faut, puis les afficher !

let infos = map (\e -> (entryTitle e, entryId e)) entries
mapM_ (\(x,y) -> putStrLn $ (stringize x) ++ ": " ++ y) infos

Oui, oui, ça se complique un peu.
Tout d'abord, qu'est-ce que infos ? map transforme chaque élément en l'image de l'élément donné par son premier argument, qui est donc une fonction. Ici, on va transformer chaque Entry en un couple (titre, id) associé à notre entrée, où id se trouve être l'URL originale du billet.
Bon infos est donc la liste des couples (titre, url). Ah ? Ce n'étant pas tellement cette ligne qui vous faisait peur mais la suivante ?
Bon, sans rentrer en détail dans les monades (la page Monad du HaskellWiki le faisant mieux que moi, et surtout donnant d'excellents liens pour comprendre de quoi il s'agit, où c'est utilisé, etc), on se trouve dans la monade IO. mapM_ se retrouve donc avec le type :

(a -> IO b) -> [a] -> IO ()

Notre [a], c'est infos, donc notre liste de couples...
(a -> IO b) est effectivement le type de notre fonction anonyme, que je me permets de vous montrer à part ici :

\(x,y) -> putStrLn $ (stringize x) ++ ": " ++ y

A un couple (titre,url), elle associe un appel à putStrLn, qui retourne IO (). Donc le type b est en fait (). mapM_ ne faut qu'effectuer des actions dans une monade donnée, en ignorant le résultat de chacune au lieu de les placer des une liste comme le fait son homologue mapM

Ah oui, j'oubliais, stringize, qui est définie juste après fonction main.

stringize :: TextContent -> String
stringize (TextString s) = s
stringize _ = error "shoud not be called on something else than TextString"

Elle me permet juste de passer d'une valeur construite avec TextString, donc de type TextContent, à la valeur qui est en fait englobée par ce type, de type String.

Voilà donc le code complet :

import Network.Download
import Text.Atom.Feed
import Text.Feed.Import
import Text.Feed.Types
 
url = "http://planet.ocamlcore.org/atom.xml"
 
main = do
    putStrLn "*** Recent blog posts ***"
    Right src <- openURIString url
    let Just (AtomFeed is) = parseFeedString src
    let entries = feedEntries is
    let infos = map (\e -> (entryTitle e, entryId e)) entries
    mapM_ (\(x,y) -> putStrLn $ (stringize x) ++ ": " ++ y) infos
 
stringize :: TextContent -> String
stringize (TextString s) = s
stringize _ = "stringize Error"

La compilation :

$ ghc -package download -o cwn cwn.hs

Et un exemple d'execution :

$ ./cwn
*** Recent blog posts ***
ocaml-text: http://forge.ocamlcore.org/projects/ocaml-text/
0.1.3 sources now in subversion: http://forge.ocamlcore.org/forum/forum.php?forum_id=355
Sudoku in ocamljs, part 2: RPC over HTTP: tag:blogger.com,1999:blog-1445545651031573301.post-3490486535879812384
Caml Weekly News, 28 Apr 2009: http://alan.petitepomme.net/cwn/2009.04.28.html
Bouncing Ball in OCaml with OCamlSDL: http://blog.mestan.fr/?p=31
Sudoku in ocamljs, part 1: DOM programming: tag:blogger.com,1999:blog-1445545651031573301.post-4574121943207730951
Using OCaml’s module functors to provide monadic contexts for Batteries: http://blog.mestan.fr/?p=30
Lastfm no longer free as in free beer (and some bits about xml in OCaml): http://blog.rastageeks.org/spip.php?article34
Last lecture: http://dutherenverseauborddelatable.wordpress.com/?p=571
Liquidsoap now supports AAC+ encoding.: http://blog.rastageeks.org/spip.php?article33

Alors, pas si "académique" que ça le fonctionnel, non ?
Tout ça en 18 lignes, lignes vides comprises, 15 non comprises.

Enjoy.

Comme demandé récemment par l'un des membres, il est tout à fait possible de faire de la 3D avec OpenGL en OCaml. Il y a principalement 2 bindings.

• LablGL
• GlCaml

Exemple d'utilisation de GlCaml

Juste pour vous donner une idée, voici un extrait du code correspondant au screenshot ci-dessus. Il s'agissait ici de montrer que ça existe, à quoi ça ressemble et où trouver le nécessaire pour s'y mettre.

let draw_gl_scene () =
    glClear  (gl_color_buffer_bit lor gl_depth_buffer_bit) ;		 (* Clear The Screen And The Depth Buffer *)
    glLoadIdentity  () ;				 (* Reset The View*)
 
    glTranslatef 0.0 0.0 !z ;                   (* move z units out from the screen. *)
 
    glRotatef !xrot 1.0 0.0 0.0 ;		 (* Rotate On The X Axis *)
    glRotatef !yrot 0.0 1.0 0.0 ;		 (* Rotate On The Y Axis *)
 
    glBindTexture gl_texture_2d  texture.(!filter) ;    (* choose the texture to use. *)
 
    glBegin gl_quads ;		                 (* begin drawing a cube *)
 
     (* Front Face  note that the texture's corners have to match the quad's corners  *)
    glNormal3f  0.0  0.0  1.0 ;                               (* front face points out of the screen on z. *)
    glTexCoord2f 0.0  0.0 ; glVertex3f (-.1.0)  (-.1.0)   1.0 ;	 (* Bottom Left Of The Texture and Quad *)
    glTexCoord2f 1.0  0.0 ; glVertex3f  1.0  (-.1.0)   1.0 ;	 (* Bottom Right Of The Texture and Quad *)
    glTexCoord2f 1.0  1.0 ; glVertex3f  1.0   1.0   1.0 ;	 (* Top Right Of The Texture and Quad *)
    glTexCoord2f 0.0  1.0 ; glVertex3f (-.1.0)   1.0   1.0 ;	 (* Top Left Of The Texture and Quad *)
 
     (* Back Face *)
    glNormal3f  0.0  0.0 (-.1.0) ;                               (* back face points into the screen on z. *)
    glTexCoord2f 1.0  0.0 ; glVertex3f (-.1.0)  (-.1.0)  (-.1.0) ;	 (* Bottom Right Of The Texture and Quad *)
    glTexCoord2f 1.0  1.0 ; glVertex3f (-.1.0)   1.0  (-.1.0) ;	 (* Top Right Of The Texture and Quad *)
    glTexCoord2f 0.0  1.0 ; glVertex3f  1.0   1.0  (-.1.0) ;	 (* Top Left Of The Texture and Quad *)
    glTexCoord2f 0.0  0.0 ; glVertex3f  1.0  (-.1.0)  (-.1.0) ;	 (* Bottom Left Of The Texture and Quad *)
 
     (* Top Face *)
    glNormal3f  0.0  1.0  0.0 ;                               (* top face points up on y. *)
    glTexCoord2f 0.0  1.0 ; glVertex3f (-.1.0)   1.0  (-.1.0) ;	 (* Top Left Of The Texture and Quad *)
    glTexCoord2f 0.0  0.0 ; glVertex3f (-.1.0)   1.0   1.0 ;	 (* Bottom Left Of The Texture and Quad *)
    glTexCoord2f 1.0  0.0 ; glVertex3f  1.0   1.0   1.0 ;	 (* Bottom Right Of The Texture and Quad *)
    glTexCoord2f 1.0  1.0 ; glVertex3f  1.0   1.0  (-.1.0) ;	 (* Top Right Of The Texture and Quad *)
 
     (* Bottom Face   *)     
    glNormal3f  0.0  (-.1.0)  0.0 ;                              (* bottom face points down on y.  *)
    glTexCoord2f 1.0  1.0 ; glVertex3f (-.1.0)  (-.1.0)  (-.1.0) ;	 (* Top Right Of The Texture and Quad *)
    glTexCoord2f 0.0  1.0 ; glVertex3f  1.0  (-.1.0)  (-.1.0) ;	 (* Top Left Of The Texture and Quad *)
    glTexCoord2f 0.0  0.0 ; glVertex3f  1.0  (-.1.0)   1.0 ;	 (* Bottom Left Of The Texture and Quad *)
    glTexCoord2f 1.0  0.0 ; glVertex3f (-.1.0)  (-.1.0)   1.0 ;	 (* Bottom Right Of The Texture and Quad *)
 
     (* Right face *)
    glNormal3f  1.0  0.0  0.0 ;                               (* right face points right on x. *)
    glTexCoord2f 1.0  0.0 ; glVertex3f  1.0  (-.1.0)  (-.1.0) ;	 (* Bottom Right Of The Texture and Quad *)
    glTexCoord2f 1.0  1.0 ; glVertex3f  1.0   1.0  (-.1.0) ;	 (* Top Right Of The Texture and Quad *)
    glTexCoord2f 0.0  1.0 ; glVertex3f  1.0   1.0   1.0 ;	 (* Top Left Of The Texture and Quad *)
    glTexCoord2f 0.0  0.0 ; glVertex3f  1.0  (-.1.0)   1.0 ;	 (* Bottom Left Of The Texture and Quad *)
 
     (* Left Face *)
    glNormal3f (-.1.0)  0.0  0.0 ;                               (* left face points left on x. *)
    glTexCoord2f 0.0  0.0 ; glVertex3f (-.1.0)  (-.1.0)  (-.1.0) ;	 (* Bottom Left Of The Texture and Quad *)
    glTexCoord2f 1.0  0.0 ; glVertex3f (-.1.0)  (-.1.0)   1.0 ;	 (* Bottom Right Of The Texture and Quad *)
    glTexCoord2f 1.0  1.0 ; glVertex3f (-.1.0)   1.0   1.0 ;	 (* Top Right Of The Texture and Quad *)
    glTexCoord2f 0.0  1.0 ; glVertex3f (-.1.0)   1.0  (-.1.0) ;	 (* Top Left Of The Texture and Quad *)
 
    glEnd  ();                                     (* done with the polygon. *)
 
    xrot := !xrot +. !xspeed;		                 (* X Axis Rotation	 *)
    yrot := !yrot +. !yspeed		                 (* Y Axis Rotation *)

PS : aucun des deux ne semble être encore maintenu, toutefois GlCaml prend en charge les versions d'OpenGL jusqu'à 2.1 + extensions ARB et spécifiques aux vendeurs. GlCaml embarque un binding minimal de la SDL, moins complet que OCamlSDL que j'ai présenté dans un post précédent.

J'ai écrit un petit programme OCaml de Boucing Ball, une balle qui rebondit contre les bords de la fenêtre, où l'on peut augmenter la vitesse en X et en Y avec les touches du clavier.
Il utilise OCamlSDL, un binding de la désormais célèbre bibliothèque SDL pour le langage OCaml.

Voici ce que cela donne.

Boucing Ball en action

Si vous voulez tester et/ou améliorer ce programme, qui peut soit dit en passant servir de base pour un Pong ou autre jeu de ce genre, vous trouverez le code source ici : bbsdl.tar.gz.

Enjoy.

Cela fait maintenant un moment que j'apprends et pratique la programmation fonctionnelle, aussi bien sur le point de vue théorique en m'intéressant à ses relations avec la théorie des catégories (mathématiques) entre autres, que sur le point de vue pratique, c'est à dire que j'ai mené quelques projets (de petite envergure... oui, c'est proportionnel au temps que je peux passer dessus) à bien.

Quand on dit "langage fonctionnel" ou "programmation fonctionnelle", les gens s'imaginent (pour ceux qui ne connaissent pas) des programmes avec tout un tas de fonctions, c'est tout. Ce n'est pas ça la programmation fonctionnelle. Enfin biensûr il y a des fonctions, mais la programmation fonctionnelle ne s'arrête pas là.

Déjà, la programmation fonctionnelle, c'est une toute autre façon de concevoir des programmes. Détailler toutes les différences avec la programmation impérative serait pire que les 12 travaux d'Hercules et c'est pourquoi je ne le ferai pas. Je vais toutefois vous parler des points qui font que je suis désormais adepte de ce style de programmation.

Tout d'abord, étant assez orienté mathématiques, il y a une première chose qui me plaît. Dans les langages de programmation fonctionnelle (du moins la plupart), on définit des types, des opérations sur ces types, le tout très simplement et de manière on ne peut plus cohérente.

Ensuite, pour les langages fonctionnels compilés et typés statiquement, on est généralement accompagné d'un compilateur très strict, qui tentera d'éliminer un maximum d'incohérences (comprendre "erreurs") en nous envoyant des erreurs très précises en rapport avec le fait que nous n'avons pas bien typé des parties de notre programme. De plus, les 3 langages majeurs pour une utilisation "real world", Haskell, OCaml et F#, ont vu leur compilateur se doter de l'inférence de type ; il s'agit de la capacité qu'a un compilateur a donner lui-même un type à vos valeurs dans le programme (fonctions, expressions, ...). Entre ceci et la vérification des types, la compilation possède une part de travail autour des types en action dans votre code.

De plus, en programmation fonctionnelle, il s'agit de ne pas avoir ce que l'on appelle des effets de bords ; on parle de programmation fonctionnelle pure ; dans un tel cadre, une fonction à qui l'on donne les mêmes entrées renverra toujours la même sortie. Les programmeurs fonctionnels font en sorte d'isoler les parties pour lesquelles ce n'est pas vrai (lecture d'un fichier, intéraction réseau, ...) : monades en Haskell, on laisse la possibilité de faire de l'impératif pour OCaml et F#, ...

Continuons sur la curryfication. Cette dernière consiste à faire par exemple d'une fonction de 2 arguments 2 fonctions à 1 argument, qui pourront s'appliquer partiellement. Si l'on définit une fonction "add" pour ajouter 2 nombres x et y, alors on pourra appliquer add à son premier argument, x, en lui donnant par exemple la valeur 12, pour obtenir une fonction à UN SEUL argument qui additionnera son argument à 12.

Les fonctions sont capitales en programmation fonctionnelle. Contrairement à dans un certain nombre de langages (beaucoup), les fonctions peuvent être stockées, passées en argument, construites à la volée, retournées par d'autres fonctions, etc. Elles deviennent des valeurs de première classe.

A propos du passage en argument, une chose très importante en programmation fonctionnelle est la possibilité d'abstraire une partie des algorithmes et d'en confier la responsabilité à une fonction donnée en argument par exemple. Une fonction qui prend une autre fonction en argument est appelée "fonction d'ordre supérieur". Cela permet de factoriser un maximum de code tout en laissant la variabilité possible grâce au passage de fonction en argument. Le compilateur fera les vérifications nécessaires pour voir si les types concordent, ne vous inquiétez pas.

La paresse est également quelque chose qui s'avère bien sympathique parfois. Il s'agit de n'évaluer une expression qu'au moment où l'on en aura besoin (affichage du résultat de l'évaluation de l'expression -- comme une addition -- par exemple). Elle est mise en oeuvre différemment selon les langages (implicitement en Haskell, c'est le compilateur qui gère cela, alors que c'est explicit en OCaml -- module Lazy).

Tout cela, rajouté aux syntaxes assez simples, donne une très grande expressivité aux langages fonctionnels, proche de l'expressivité que l'on a en mathématiques. Qui plus est, rappelons-le, les langages fonctionnels sont des langages dits "déclaratifs". On exprime le problème, on obtient la solution, contrairement à ce que l'on fait dans un langage impératif où l'on doit donner toutes les étapes à la main nous-mêmes.

Bref, beaucoup d'avantages, un tout nouveau style de programmation, cela ne vaut-il pas le détour ? Allez, si vous voulez en savoir plus, voici quelques liens essentiels pour terminer ce billet sur la programmation fonctionnelle.
Cours d'introduction à OCaml de Damien Guichard -- dont je me suis beaucoup servi et que j'apprécie beaucoup
Traduction de "A gentle introduction to Haskell" -- un peu rude pour débuter, mais vous fera comprendre pas mal de choses.

N'hésitez pas à utiliser le forum pour donner vos avis et retours d'expérience ou pour des questions, bien évidemment !

Étant tombé amoureux du langage OCaml, et comptant propulser cette activité de blog sur Coder-Studio, j'aimerais savoir ce que vous, amateur du langage OCaml, de la programmation fonctionnelle en général ou tout simplement curieux, vous souhaiteriez lire en rapport avec OCaml sur notre site préféré

Alors ?
Quelques grandes lignes qui pourraient intéresser :
- OCaml et les maths (comme mon billet précédent)
- OCaml et les GUIs
- OCaml et le multimédia (OCamlSDL, OCaml/OpenGL, ...)
- OCaml et la conception de compilateurs/interpréteurs (lexing, parsing, etc)
- ...

Merci de donner votre avis !

Un billet à propos d'OCaml, encore. Je me suis amusé à implémenter la construction de l'Ensemble de Cantor (version anglaise un peu plus complète). Vous voulez en savoir plus ?

Première étape, il me fallait une fonction qui à partir d'une liste et d'un couple (a,b) de nombre réels, représentant l'intervalle [a,b], rajoute les deux intervalles qui en sont générés par une itéraction de la construction de l'ensemble de Cantor, c'est à dire les intervalles [a, (2a+b)/3] et [(a+2b)/3, b], à la liste. Voici la fonction en question, appelée cantor_step ici :

let cantor_step l (a,b) =
 (a, (a +. a +. b) /. 3.) :: ((a +. b +. b) /. 3., b) :: l

Ensuite, il fallait une fonction qui permettre d'appliquer cette fonction sur une liste de couples (a,b) pour passer d'une liste d'intervalles à une autre, c'est à dire passer à l'étape suivante de la génération de l'Ensemble de Cantor. J'ai par la même occasion profité pour rajouté un paramètre n permettant de réaliser cela n fois. J'ai appelé cette fonction map_n.

let map_n f l n = match l with
  | [] -> []
  | l -> aux l n 
      where
	rec aux l = function 
	  | 0 -> l
	  | k -> aux (List.fold_left f [] l) (k-1)

List.fold_left est ce que l'on appelle un "pliage" (fold en Anglais). Pour vous familiariser avec ces derniers, une recherche sur "functional programming fold" devrait vous apporter le nécessaire ). Il permet de parcourir la liste d'une certaine façon en appliquant une certaine fonction sur l'élément courant et le résultat de ce qui a été fait jusque là de la même façon, et ainsi de suite.

Enfin, définissons une fonction nth_cantor qui permet d'obtenir la liste des intervalles qui constituent la n-ème itéraction de la construction de l'Ensemble de Cantor.

let nth_cantor = function
  | 0 -> [(0.,1.)]
  | k -> map_n cantor_step [(0.,1.)] k

On voit donc que l'on part de l'intervalle [0,1], et que l'on va répéter k fois l'itéraction.

Deux fonctions utilitaires, dont une qui utilise non pas le module List standard mais le module List de OCaml Batteries Included, pour la fonction print. (en fait, List.fold_left ci-dessus est également celui de OCaml Batteries Included, étant donné que le programme sera compilé avec OCaml Batteries Included).

let couple_printer output (a,b) = Printf.printf "(%f,%f)\n" a b
 
let list_printer l =  (* List.print couple_printer stdout l ;*)  Printf.printf "\n%d intervals in list\n" (List.length l)

La première permet d'afficher un couple de réels depuis ... un couple de réels.
La seconde permet d'afficher une liste en précisant quelle fonction utiliser pour afficher chaque élément. Elle affiche ensuite la taille. Ici, le passage d'affichage des éléments est commenté (entre (* ... *)) car ayant testé mon code avec notamment 25 itérations, on se retrouve avec beaucoup trop de choses à afficher pour que ça soit supportable pour un être humain normal.

Enfin, le code qui est exécuté :

let main () = 
  try 
    let n = int_of_string Sys.argv.(1) in
    let cn = nth_cantor n in
      list_printer cn
  with _ -> print_endline "Use : ./cantor n, where n is an integer" ; exit 0
 
let _ = main ()

Pour terminer, la compilation :

$ ocamlfind batteries/ocamlopt -o cantor cantor.ml

(pas d'optimisation ici, si vous les voulez, rajouter -cc -On après ocamlopt)

Et on exécute :

$ time ./cantor 25
33554432 intervals in list

real 0m25.553s
user 0m23.481s
sys 0m2.060s

En activant l'affichage des éléments, sur un petit nombre d'itérations :

$ time ./cantor 4
[(0.740741,0.753086)
; (0.765432,0.777778)
; (0.666667,0.679012)
; (0.691358,0.703704)
; (0.962963,0.975309)
; (0.987654,1.000000)
; (0.888889,0.901235)
; (0.913580,0.925926)
; (0.074074,0.086420)
; (0.098765,0.111111)
; (0.000000,0.012346)
; (0.024691,0.037037)
; (0.296296,0.308642)
; (0.320988,0.333333)
; (0.222222,0.234568)
; (0.246914,0.259259)
]
16 intervals in list

real 0m0.013s
user 0m0.000s
sys 0m0.016s

Vous avez surement remarqué que cette méthode ne préserve pas l'ordre des intervalles... Ce n'a pas vraiment été mon soucis premier, et ce serait arrangé avec la méthode décrite ci-dessous.

Au passage, si j'utilisais des arbres binaires pour toutes les étapes intermédiaires et que je produisais une liste depuis cet arbre, je gagnerais pas mal en efficacité, disons que je vous le laisse à titre d'exercice

Enjoy !

PS : la capture d'écran ci-dessus provient d'un programme que j'avais réalisé il y a quelques mois et qui faisait une construction itérative représentée graphiquement, mais la méthode de génération était moins efficace, et j'ai la flemme de refaire la même chose maintenant...

Peut-être avez-vous déjà entendu parler de ce projet ... OCaml Batteries Included.

Ce projet couvre pour le moment un certain nombre de domaines. Il fournit une certaine quantité de structures de données, de fonctions pour la programmation concurrente, etc. Qui plus est, il inclut des extensions de syntaxes qui pourront s'avérer très utile, ainsi que de nouveaux opérateurs pour rendre le code OCaml plus lisible et concis, ce qui finalement fait gagner en lisibilité (notamment pour l'enchainement de fonctions, comme lorsque l'on appelle une série de fonctions opérant sur une chaîne de caractères, en passant le résultat d'une fonction à la suivante, et ainsi de suite). Je ne vais pas lister les bibliothèques, ce serait trop long.

OCaml Batteries Included est sortie en version Bêta 1 il y a quelques jours. Qui plus est, l'équipe OCaml-Debian-Maintainers a mis à disposition un paquet ocaml-batteries-included qui est dans le dépôt testing officiel, n'hésitez pas !

Pour finir, quelques liens :
Site officiel
Documentation de l'API
Documentation de la plateforme
Billet de blog sur la publication de la Beta 1

Enjoy !