Alp Mestan :: Blog » Programmation Fonctionnelle

(Petit) Clône de client telnet en Haskell

Alp — Fri, 28 Aug 2009 11:58:57 +0000

Bonjour,

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à donc 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

Pour compiler (j’ai tout ce code dans un fichier net.hs :
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

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 !

Haskell Platform, ou comment se mettre à Haskell sans soucis !

Alp — Mon, 24 Aug 2009 16:22:37 +0000

Bonjour à tous,

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 (comme doxygen pour le C++).

Le tout se configurant automatiquement, bien évidemment.

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

Par la suite, vous pourrez donc par exemple lancer le toplevel associé, nommé ghci, en lançant par exemple depuis un invite de commande sous Windows, ou depuis n’importe quel terminal sous les systèmes UNIX-like :

$ ghci
GHCi, version 6.10.4: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer ... linking ... done.
Loading package base ... linking ... done.

Et vous pourrez ensuite commencer à vous amuser avec ghci :

Prelude> 42^42
150130937545296572356771972164254457814047970568738777235893533016064
Prelude> foldr (+) 0 [1,2,3,4,5,6]
21
Prelude> "Salut" ++ " Developpez !"
"Salut Developpez !"

Pour rappel, si vous désirez apprendre Haskell :
> http://gorgonite.developpez.com/livres/traductions/haskell/gentle-haskell/ (fr)
> http://book.realworldhaskell.org/read/ (en)

Récupération et traitement d’un flux Atom XML en Haskell

Alp — Tue, 16 Jun 2009 03:20:10 +0000

Bonsoir,

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

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.

PS : on pourrait raccourcir et rendre le code moins compréhensible en utilisant des opérateurs et moins de valeurs intermédiaires, mais ce n’est pas l’objectif ici.

Hello Gtk2Hs !

Alp — Fri, 12 Jun 2009 17:02:07 +0000

Bonjour,

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é :

Hello, Developpez !
400
400

Bonjour Developpez, comment vas-tu ?

Je suis un programme Haskell qui utilise
Gtk2Hs, binding Haskell de GTK+.

Clique pour fermer.
True
True
True

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 ?

La programmation fonctionnelle n’est pas un jouet académique

Alp — Fri, 06 Mar 2009 05:27:28 +0000

Bonjour,

Je souhaitais écrire un billet à propos de la programmation fonctionnelle, ce sera chose faite.

Cela fait maintenant plus de 6 mois 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.
Forums sur les langages fonctionnels
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 !