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 !