A quick work regarding the current status of Extrapol and its release.

Development of Extrapol progresses. With our current set of sample, Extrapol works flawlessly. We’re now adding features, improving error reporting and de-hard-wiring the model of the C standard library from the tool and moving it towards an external configuration file as well as progressively moving towards larger and more realistic samples. Development will come to an abrupt (and temporary) halt at the end of this week, though, due to personal matters (i.e. I’m getting married).

The release planned for next week, on the other hand, is canceled. As the research field of applied security is very competitive, and after careful discussion with the rest of my research team, we have decided to only release a version of Extrapol after the scientific content has been accepted for publication in a conference or journal. At the request of one of the institutes which founds this research, I will also refrain from posting detailed information on the theory and algorithms behind Extrapol, until these are cleared by the institute and accepted for publication. Without entering the details, Extrapol is expected to serve in critical infrastructures, which explains the need for clearance.

However, rest assured that there will be a release and it will be open-source (presumably licenced under a combination of MIT and LGPL). The only question is when — and this probably won’t happen before November.

Short version

Catch me if you can is a small library for OCaml 3.10. The latest release is version 0.2, which you may find here. This library improves management of errors in OCaml. It is released under the LGPL licence. It has been written by David Teller, Arnaud Spiwack, Till Varoquaux and Gabriel Scherer.

Long version

As all languages of the ML family — and most modern languages indeed — OCaml permits the management of exceptional situations using exceptions. This mechanism lets programmer register protected sections of code, as well as exception handlers to handle any exception which may be raised during the execution of a protected section. Whenever an exception is raised, the protected section of code is immediately stopped and the corresponding exception handler is executed instead. In addition, exceptions may convey some information regarding the nature of the exceptional circumstance.

In OCaml, the mechanism is fast, it’s convenient and it’s type-safe, much like the rest of the language (barring any type-unsafe interaction with C). However, a few things are missing. If we consider the rest of the language, exceptions are both heavyweight and clumsy: each exception must be declared before being used and there’s no way to introduce a polymorphic type parameter in the exception. In addition, languages such as Java offer to important features missing in OCaml: automatic case coverage and exception hierarchies. While a nice tool exists  to provide case coverage for exceptions in OCaml, this tool is complex and  unfortunately unmaintained.

Catch me if you can offers an alternative mechanism, comparable to ML exceptions, to handle errors. In comparison with OCaml’s native exception mechanism, this library adds:

• automatic inference of exceptions (i.e. no need to declare your exceptions, unless you want to)
• more flexible exceptions (i.e. exceptions may have polymorphic type parameters, constraints, etc.)
• hierarchies (i.e. an IOException is a sub-case of Exception and a super-case of NetworkException)
• case coverage (i.e. the compiler can tell you if you forgot a case or sometimes if you wrote useless ones)
• conditional success handlers (i.e. do something with the result in case of success)
• conditional success-and-failure handlers (i.e. “finally”).

To attain this, we replace the mechanism of exceptions by an error monad, we replace exception constructors with polymorphic variants and we introduce a dose of syntactic sugar.

Examples

Expression evaluator

Let’s write a simple expression evaluator for the following set of expressions:

type expr =
  | Value of float
  | Div     of expr * expr
  | Add    of expr * expr
  | Mult   of expr * expr
  | Subs  of expr * expr

These may be evaluated using the following function:

let rec eval = function
 | Value x    -> x
 | Add (x,y) -> eval x +. eval y
 | Mult(x,y)  -> eval x *. eval y
 | Div(x,y)   -> eval x /. eval y
 | Subs(x,y) -> eval x -. eval y

Of course, this function is bound to fail in case of division by zero. While this is expected, there is nothing in the source code — much less in the type of the function — to let us know which exception will be raised in case of division by zero.

An alternative would be to add manual error checking, as follows:

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

let rec eval = function
 | Value x    -> OK x
 | Add (x,y) -> (match eval x with
                      | Error e -> Error e
                      | Ok x' ->  match eval y with
                               | Error e -> Error e
                               | Ok y'    -> Ok (x' +. y'))
 | Mult (x,y) -> (match eval x with
                      | Error e -> Error e
                      | Ok x' ->  match eval y with
                               | Error e -> Error e
                               | Ok y'    -> Ok (x' *. y'))
 | Div (x,y) -> (match eval x with
                      | Error e -> Error e
                      | Ok x' ->  match eval y with
                               | Error e -> Error e
                               | Ok y'    -> if y' = 0. then Error "Division by zero"
                                                else              Ok (x' /. y'))
 | Subs (x,y) -> (match eval x with
                      | Error e -> Error e
                      | Ok x' ->  match eval y with
                               | Error e -> Error e
                               | Ok y'    -> Ok (x' -. y'))
(*eval : expr -> (float, string) result*)

After this transformation, the type of the exception appears in the type of eval — here, we used strings, but anything else would have been fine. Of course, the downside is that this is unreadable. Well, what about the following ?

let rec eval = function
 | Value x    -> return x
 | Add (x,y) -> perform with module Error
                        x' <-- eval x;
                        y' <-- eval y;
                        return (x' +. y' 
 | Mult (x,y) -> perform with module Error
                        x' <-- eval x;
                        y' <-- eval y;
                        return (x' *. y' 
 | Div (x,y) -> perform with module Error
                        x' <-- eval x;
                        y' <-- eval y;
                        if y'=0. then throw "Division by zero"
                        else            return (x' /. y' 
 | Subs (x,y) -> perform with module Error
                        x' <-- eval x;
                        y' <-- eval y;
                        return (x' -. y' 
(*eval : expr -> (float, string) result*)

This extract uses [our customized version of] Pa_monad (included in the package), which brings syntactic support for monads. While this is more verbose than the original version, it’s also safer, insofar as we can guarantee that exceptions won’t remain uncaught.

Still too long? Then what about using the appropriate operators?

open Error.Operators
let rec eval = function
 | Value x    -> x
 | Add (x,y) -> eval x +. eval y
 | Mult(x,y) -> eval x *. eval y
 | Div(x,y)   -> eval x /. eval y
 | Subs(x,y) -> eval x -. eval y

Except for the module opening, that’s the same thing as our first listing. Just with the added safety.

Throwing, catching and hierarchies

By the way, the type of the result is

(*eval : expr -> (float, [> `Arithmetic of (unit, [> `Div_by_zero of (unit, _) exc ]) exc ]) result*)

That is, eval may either succeed and return a float or fail and return an arithmetic exception, which also turns out to be a division by zero. That’s classes of exceptions.

With our syntactic sugar, raising such an exception is done by

throw (exception Arithmetic (); Div_by_zero ())

Note that we could have put some content instead of (). Note that exceptions are typed as they appear in the code and don’t need to be declared (if you wonder, polymorphic variants are involved in this).

Of course, various kinds of exceptions may be combined, as in the following extract:

match ... with
| 1 -> throw (exception Arithmetic (); Div_by_zero ())
| 2 -> throw (exception Arithmetic (); Overflow "by gosh !&quot 
| 3 -> throw (exception IO file_descr)
| ...
(*
('a, [> `Arithmetic of (unit, [> `Div_by_zero of (unit, _) exc
                                     |   `Overflow of (string, _)   exc]) exc
     |   `IO of (int, [`> ]) exc ]) result*)
*)

While the type of the expression is difficult to read, catching is easy

attempt ... with
 | val s -> (*success*)
 | Arithmetic (); Div_by_zero () -> (*Division by zero*)
 | Arithmetic (); _                   -> (*Other arithmetic*)
 | IO _                                  -> (*Some IO stuff *)
 | finally _                             -> (*Don't forget to close the door*)

This extract introduces three keywords:

• attempt is our replacement for try
• val is used to pattern-match against the result of a successful evaluation
• finally is used to pattern-match against the final result, whether this result was obtained after a successful evaluation or after an exception was raised and handled.

Unbreaking tail-recursion

The following extract is wrong:

let line_count filename =
  let rec loop file count =
  try
    ignore (input_line file);
    loop file (count + 1)
  with
    End_of_file -> count
  in
    loop (open_file filename) 0

Don’t get me wrong, it will compile and run. The problem is that it’s not tail-recursive. In other words, it will be much slower and much more memory-consuming than if exceptions had been ignored. Why ? Because exception End_of_file may have been raised from the next call to loop, so the recursive call cannot be optimized into a non-recursive call. Of course, exceptions can’t be ignored in this extract, as they are required to determine when to stop reading the file. Now, a simple transformation would make the problem go away :

let line_count filename =
  let rec loop file count =
    let should_continue =
    try
      ignore (input_line file);
      true
    with End_of_file -> false
  in
    if should_continue then loop file (count + 1)
    else                    count
  in
    loop (open_file filename) 0

Well, the transformation is simple, but it’s annoying and hard to read. What’s even more annoying is that it’s quite common. With Catch me if you can, we would rather write the following:

let input_line2 x = Error.legacy input_line x

let line_count filename =
  let rec loop file count =
    attempt input_line2 file with
      | val _ -> loop file (count + 1)
      | _     -> count
  in
  loop (open_file filename) 0

In this extract, legacy is a simple manner of wrapping an existing, one-argument, function and convert it to our new exception style. It’s not quite as good as wrapping the function manually and giving it an actual exception, but it’s better than nothing.

All in all, the resulting function line_count is shorter, easier to read, takes less memory and is also faster than the original.

What about performance?

Now, that’s a complex question. Short answer: there’s an acceptable performance loss. False short answer: we wrote a paper on that subject.

A new version of the exception monad for OCaml is now available for download. It’s now richer, comes with extensive syntactic sugar and a brand new system of compile-time optimizations. More on this in the corresponding research paper — and whenever I find the time, on this blog.

A colleague recently pointed me towards Korset, a program developed by Ohad Ben-Cohen and Avishai Wool promising features comparable to Extrapol. While I must admit I’m slightly skeptical about the promise of “provable zero false alarm” — since the problem is undecidable, usually people tend to develop “provably complete” rather than “provably sound” analysis — it sounds like an interesting development.

Now, from what I understand, Korset will be presented to Blackhat in a few months, and the rules of the conference forbid the developers from giving away any detail. Until then, we have no way of comparing the unreleased Extrapol and the equally unreleased Korset.

Note: the tarball for the first prototype of Extrapol is waiting on my hard-drive for release clearance. I hope I’ll be able to release it next Tuesday or Wednseday. Stay tuned.

]]> http://dutherenverseauborddelatable.wordpress.com/2008/06/19/extrapol-and-korset/feed/ yoric http://dutherenverseauborddelatable.wordpress.com/2008/06/17/extrapol-source-code-available/ http://dutherenverseauborddelatable.wordpress.com/2008/06/17/extrapol-source-code-available/#comments Tue, 17 Jun 2008 16:08:16 +0000 yoric http://dutherenverseauborddelatable.wordpress.com/?p=96

A quick note to inform you that the repository for Extrapol is now public. The source code as available on the repository does not have a licence yet and will not compile as such, due to dependencies on libraries available somewhere else. Stay tuned for an actual release.

Update: Sorry, repository cut off by the administrator. I’ll inform you when the sources are back.

Note rapide pour vous informer que le code source d’Extrapol est maintenant disponible au public. Il ne s’agit pas encore d’une version officielle — en particulier, le code n’a pas encore de licence et il manque des bibliothèques (disponibles ailleurs). Plus de détails dès qu’une version officielle est disponible.

Additif: Désolé, je viens d’apprendre que le dépôt de source a été isolé par l’administrateur. Je vous tiendrai au courant dès que le code source est de nouveau public.

Après un billet dans la langue de Turing, voici une présentation d’Extrapol en version française. En quelques mots, le projet Extrapol (pour Extraction de Politiques de Sécurité) vise à combler un vide dans le jeu d’outils dont dispose l’administrateur pour maintenir un système dans un état sûr.

Ainsi, il existe un grand nombre de logiciels qui permettent de surveiller un processus durant son exécution (analyse dynamique) ou après son exécution (analyse de traces) afin de comprendre le comportement de programme et ainsi de vérifier que la politique de sécurité en vigueur sur le système est bien respectée. À l’inverse, les outils d’analyse statique disponibles cherchent généralement à répondre à des questions sans rapport direct avec la sécurité système, telles que “ai-je écrit une bêtise ?” ou “puis-je prouver que mon programme fonctionne ?”

Que fait ce programme ?

Les outils d’analyse dynamique, qu’il s’agisse de SELinux, de la protection mémoire Unix, de la gestion des privilèges Windows ou des autorisations Java ou .Net, visent tous à répondre à deux questions :

1. Qu’est en train de faire ce programme ?
2. Est-ce légal ?

La réponse à la deuxième question est donnée par une notion de politique de sécurité, qui se réduit généralement à un ensemble d’autorisations de la forme “le sujet S a le droit d’entreprendre l’action A sur l’objet O”. Pour répondre à la première question, la technique générale consiste à intercaler entre le programme et les APIs concernées par la surveillance une couche dont le seul rôle est de prendre en compte les appels. Sans entrer dans les détails, les outils d’analyse de trace posent des questions similaires en s’appuyant sur des notions et des techniques comparables.

Logiquement, nous avons décidé de suivre le même chemin pour Extrapol :

1. Que va faire ce programme ?
2. Puis-je savoir dès maintenant si c’est légal ?

Pour répondre à la deuxième question, nous nous proposons d’utiliser exactement la même notion de politique de sécurité que celle qui est employée dans les systèmes d’exploitation actuels — plus précisément, à terme, nous nous proposons de permettre à Extrapol d’utiliser directement les fichiers de configurations de SELinux ou d’AppArmor. Quant à la première question, nous allons en chercher la réponse par des techniques d’analyse de types sur les programmes écrits en C. Voyons cela sur un exemple :

void* read_some_stuff()
{
   FILE* file = fopen("/home/foo/bar.log", "r");
   void* buf  = malloc(1024*sizeof(int));
   fread(buf , sizeof(int), 1024, file);
   return buf;
}

Que fait donc cette fonction ? Sans nous attacher à la qualité du code — une pléthore d’outils existe déjà pour essayer de vérifier celle-ci — nous pouvons déterminer aisément que

• il s’agit d’une fonction appelée read_some_stuff
• si cette fonction est appelée, elle ouvrira en lecture le fichier nommé /home/foo/bar.log
• si cette fonction est appelée, elle consultera une partie du fichier nommé
  /home/foo/bar.log
• si cette fonction est appelée, elle renverra une information tirée du fichier nommé
  /home/foo/bar.log

En termes de sécurité, ce programme ne doit donc être accepté que dans un contexte dans lequel la politique de sécurité en vigueur sur le système autorise la consultation du fichier /home/foo/bar.log. Regardons ce que nous dit Extrapol au sujet de ce programme :

read_some_stuff: Function
        effect                 : "open" (Constant "/home/foo/bar.log" , Constant "r" )
        effect                 : "read" (Constant "/home/foo/bar.log" )
        return                 : "data read from file" (Constant "/home/foo/bar.log" )
End

Soit, en français,

• read_some_stuff est une fonction
• cette fonction ne prend aucun argument
• cette fonction a pour effet d’ouvrir le fichier nommé
  "/home/foo/bar.log" pour consultation
• cette fonction a pour effet de consulter des informations depuis le fichier nommé "/home/foo/bar.log"
• le résultat de cette fonction est un ensemble d’informations provenant du fichier nommé "/home/foo/bar.log".

Pour cet exemple, la réponse d’Extrapol est plus longue que le programme original et probablement pas beaucoup plus lisible. Regardons le résultat sur un extrait un peu plus complexe :

#include <stdio.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>

int do_open(char* file_name)
{
  int fd = (int)fopen(file_name, O_RDONLY);
  return fd;
}

int do_read(int fd)
{
  char* buf;
  buf    = (char*)malloc(1024*sizeof(char));
  int rd = 0;
  for(int i = 0; i < 1024; ++i)
    rd = rd + fread(buf, i, 1, fd);

  return buf;
}

Sans surprise, Extrapol analysera les deux fonctions et présentera un bilan pour chacune.

• L’analyse de do_open produira :

  
  do_open: Function
          input arg file_name    : Bottom
          effect                 : "open" (Identifier "file_name", Constant "0" )
          return                 : "FILE" (Identifier "file_name" )
  End
  

  c’est-à-dire,

  • do_open est une fonction
  • do_open accepte un argument, ici file_name
  • le contenu de cet argument ne sera pas modifié
  • le contenu de cet argument n’a pas besoin d’avoir une structure particulière
  • appeler cette fonction aura un effet sur le système : ouvrir ouvrir pour consultation le fichier dont le nom a été donné dans file_name
  • la fonction renvoie une information abstraite, dans ce cas un fichier dont le nom a été donné dans file_name.
• L’analyse de do_read produira :

  
  do_read: Function
          input arg fd           : "FILE" (Identifier "extrapol_generated_699 (formerly <anonymous> ) " )
          effect                 : "read" (Identifier "extrapol_generated_699 (formerly <anonymous> ) " )
          return                 : "data read from file" (Identifier "extrapol_generated_699 (formerly <anonymous> ) " )
  End
  

  c’est-à-dire,

  • do_read est une fonction
  • do_read accepte un argument, ici fd
  • le contenu de cet argument ne sera pas modifié
  • cet argument doit être une structure abstraite, dans ce cas précis un fichier
  • pour le reste de la fonction, nous appellerons le nom du fichier extrapol_generated_699 (formerly <anonymous>)" — Extrapol a été obligé d’inventer cette appellation pas très attrayante pour désigner le nom du fichier
  • cette fonction a un effet sur le système : consulter le fichier dont le nom est représenté par extrapol_generated_699 (formerly <anonymous> )
  • cette fonction renvoie une information abstraite, dans ce cas quelque chose qui a été lu depuis le fichier dont le nom est représenté par extrapol_generated_699 (formerly <anonymous> )

Maintenant, ces fonctions peuvent être utilisées et leur usage peut être analysé de la même manière que si elles avaient fait partie de la libc. Ainsi, complétons notre extrait par la fonction main suivante :

int main(int argc, char **argv) {
  assert(argc >= 1);
  int   fd  = do_open(argv[0]);
  char* buf = do_read(fd);
  free(buf);
  return 0;
}

En retour, Extrapol nous répondra :

main: Function
        input arg argc         : "command-line argument" ()
        input arg argv         : "command-line argument" ()
        input vararg           : "command-line argument" ()
        effect                 : "read" (Identifier "argv" )
        effect                 : "open" (Identifier "argv", Constant "0" )
        return                 : Constant "0"
End

En d’autres termes, le programme aura pour effet d’ouvrir puis de lire un fichier dont le nom est passé en ligne de commande.

Comment ça marche ?

Pour ce billet, je ferai semblant de comprendre cette question comme « comment utiliser Extrapol ? » La réponse est simple. Extrapol prend en entrée un ou plusieurs fichiers source C (passés ou non par le préprocesseur) et une base de connaissances sur les fonctions considérées comme primitives. Cette base de connaissance est un fichier ASCII dans le même format que les sorties d’Extrapol. Ainsi, malloc sera décrit par

malloc: Function
  input arg size: Bottom
  return: Bottom
End

En d’autres termes, malloc est une fonction qui accepte un argument (”size“) quelconque et renvoie une valeur dont il est possible de faire n’importe quoi. Une fonction telle que fread sera un peu plus compliquée. Commençons par regarder le manuel de cette fonction :

size_t fread(void *ptr, size_t size, size_t nmemb, FILE *stream);

Pour Extrapol, il s’agit d’une fonction à 4 arguments et une valeur de retour. Commençons par la fin.

• La valeur de retour peut être n’importe quoi, nous n’allons faire aucune garantie. En Extrapol, c’est ce que nous notons Top — par opposition à Bottom, qui signifierait au contraire qu’il n’y a aucune contrainte sur la valeur. Si nécessaire, nous pourrions raffiner ceci.
• Le dernier argument est un fichier. Nous avons vu un peu plus tôt comment représenter les fichiers : ce sont des structures abstraites que nous avons décidé, par convention, d’appeler FILE, comme dans la bibliothèque standard de C. Plus précisément, nous avons décidé de les noter "FILE" (toto) où toto permet de déterminer le nom du fichier. Nous appelons "FILE" un constructor, au sens de la réécriture ou de la programmation fonctionnelle. Il s’agit en tout et pour tout d’une chaîne de caractères dont nous nous servons pour différencier les valeurs abstraites. Le toto correspondant est l’argument donné au constructeur.
• L’avant-dernier paramètre de la fonction est le nombre de blocs à lire. Nous allons juste l’ignorer, c’est-à-dire ne mettre aucune contrainte, c’est-à-dire Bottom.
• Le deuxième argument est une taille, que nous allons aussi ignorer, c’est-à-dire de nouveau Bottom.
• Enfin, le premier paramètre est utilisé en sortie — fonctionnellement, c’est une forme spéciale de return. Nous allons donc le marquer output. Nous pourrions nous arrêter là et ne mettre aucune garantie sur le contenu de ce paramètre, mais ici nous allons légèrement raffiner et spécifier qu’il s’agit d’informations certes inconnues, mais lues depuis un fichier. Comme précédemment, il s’agit d’une structure abstraite, donc d’un constructeur, que nous allons appeler "data read from file". Comme argument, nous allons passer le nom du fichier d’où viennent les informations. Nous obtenons donc "data read from file"(toto). La valeur de toto sera déterminée lors de l’invocation de la fonction grâce à la valeur du dernier argument.
• Oh, et avant d’oublier, cette fonction a un effet sur le système : elle lit quelque chose depuis toto. Appelons cet effet "read"(toto)

Ou, en Extrapol dans le texte :

fread: Function
   output arg ptr: "data read from file" ( Identifier "path" )
   input arg size : Bottom
   input arg nmemb: Bottom
   input arg stream: "FILE" ( Identifier "path" )
   return: Top
   effect: "read" ( Identifier "path" )
End

Une fois données cette base de connaissances et des fichiers C, Extrapol va passer les fichiers au pré-processeur, analyser lexicalement et syntaxiquement le contenu des fichiers, puis procéder par déductions successives à partir de la structure du programme et de la base de connaissances. Chaque fonction analysée est ajoutée à la base de connaissances pour pouvoir être réutilisée dans la suite du programme. Extrapol continue soit jusqu’à avoir tout analysé, soit jusqu’à un problème interne (typiquement une fonction avec le mauvais nombre d’arguments ou une fonction utilisée sans avoir été définie).Enfin, Extrapol affiche le résultat de ses déductions, à un format ré-utilisable pour réinjection dans la base de connaissances.

Si vous êtes curieux, les principes derrière Extrapol sont

• le lambda-calcul et, plus généralement, la programmation fonctionnelle
• les systèmes de types avec effets
• les systèmes de types dépendants
• l’inférence de types à la Hindley-Milner .

Tout ceci sera détaillé dans un ou plusieurs autres billets — et dans un article de journal scientifique que je viens de commencer.

Est-ce que ça marche ?

La réponse à cette question est un clair et franc “oui, non et peut-être” :

• Tout n’est pas implanté. En particulier, pour le moment, Extrapol n’est pas capable de déduire quoi que ce soit d’intéressant sur les variables globales. De même, Extrapol n’aboutira pour le moment que si les fonctions sont introduites dans l’ordre dans lequel elles sont utilisées. Rien de terriblement difficile à ajouter à Extrapol, cela n’a juste pas été prioritaire jusqu’à présent.
• Extrapol n’est capable de gérer ni la récursivité ni les pointeurs sur fonctions. Pour le moment, la théorie derrière Extrapol ne prend pas en compte ces aspects du langage C.
• Tous les exemples cités ci-dessus fonctionnent, ainsi que quelques dizaines d’autres.
• Nous n’avons pas encore confronté Extrapol avec des logiciels complets. Le jour où Extrapol comprendra, mettons tar ou ls, nous déboucherons le champagne.

Comment est-ce écrit ?

Il y a actuellement deux versions d’Extrapol :

• Extrapol/Java, version implantée en Java par Bastien Jansen, Steve-William Kissi et David Teller. Environ 18.000 lignes de code.
• Extrapol/ML, version expérimentale, implantée en OCaml par David Teller. Environ 4.000 lignes de code.

Les deux versions seront libérées sous peu (normalement d’ici la mi-juin), dès que nous serons arrivés à régler des problèmes techniques dans notre serveur de projet et dès que nous aurons fini par décider d’une licence. A priori, ce sera probablement Cecill B pour Extrapol/Java et LGPL pour Extrapol/ML.

Here comes the long-promised description of Extrapol, my main ongoing research project. In a few words, our objective with Extrapol is to fill a hole in the current suite of tools built to ensure the security of systems. While there’s an ample amount of stuff designed to analyse the behaviour of processes either during their execution (dynamic analysis) or after their completion (trace analysis), there is little work on applying static analysis to actual system security.

What does this program do?

Whether we’re talking about SELinux, AppArmor, the Unix memory protection, ACLs, every form of dynamic analysis is trying to find the answer to two questions:

1. what is this program doing?
2. is that legal?

With Extrapol, the questions are similar, although we’re asking them earlier — and restricting ourselves to C programs:

1. what is this program going to do whenever it gets executed?
2. is that legal?
3. if information is missing, where will that information come from?

Let’s look at an example and see what gives:

void* read_some_stuff()
{
   FILE* file = fopen("/home/foo/bar.log", "r");
   void* buf  = malloc(1024*sizeof(int));
   fread(buf , sizeof(int), 1024, file);
   return buf;
}

Now, what does this function do? Now, regardless of the quality of the code, from a cursory read, it’s quite clear that it

• opens a file named “/home/foo/bar.log” for reading
• allocates some memory
• read some of the content of that file
• return a pointer to the contents of that file.

In terms of security, the program should only be executed by a user who has the authorization to read file “/home/foo/bar.log” and only if that user is willing to let the program read the contents of that file. Let’s see what Extrapol tells us about the extract:

read_some_stuff: Function
        effect                 : "open" (Constant "/home/foo/bar.log" , Constant "r" )
        effect                 : "read" (Constant "/home/foo/bar.log" )
        return                 : "data read from file" (Constant "/home/foo/bar.log" )
End

In clear(er) English, Extrapol has just given us the following informations:

• read_some_stuff is a function
• read_some_stuff does not take any argument
• if executed, this function will have the secondary effect of opening a file named “/home/foo/bar.log” for reading
• if executed, this function will also have the secondary effect of reading stuff from a file named “/home/foo/bar.log”
• the result of calling this function is some data read from the file named “/home/foo/bar.log”

While the result is somewhat larger than the original program, of course, we can apply Extrapol to more complex programs. Say, from

#include <stdio.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>

int do_open(char* file_name)
{
  int fd = (int)fopen(file_name, O_RDONLY);
  return fd;
}

int do_read(int fd)
{
  char* buf;
  buf    = (char*)malloc(1024*sizeof(char));
  int rd = 0;
  for(int i = 0; i < 1024; ++i)
    rd = rd + fread(buf, i, 1, fd);

  return buf;
}

Well, in that case, Extrapol will analyze both functions and produce a summary of each.

• The analysis of do_open will result in:

  
  do_open: Function
          input arg file_name    : Bottom
          effect                 : "open" (Identifier "file_name", Constant "0" )
          return                 : "FILE" (Identifier "file_name" )
  End
  

  that is,

  • do_open is a function
  • do_open accepts one argument file_name
  • the content of this argument won’t be modified
  • this argument doesn’t seem to require to contain anything specific
  • the function has one system effect: opening for reading the file whose name was given as file_name
  • the function returns some abstract data, in that case a file whose name name was given as file_name.
• The analysis of do_read will result in:

  
  do_read: Function
          input arg fd           : "FILE" (Identifier "extrapol_generated_699 (formerly <anonymous> ) " )
          effect                 : "read" (Identifier "extrapol_generated_699 (formerly <anonymous> ) " )
          return                 : "data read from file" (Identifier "extrapol_generated_699 (formerly <anonymous> ) " )
  End
  

  that is,

  • do_read is a function
  • do_read accepts one argument fd
  • the content of this argument won’t be modified
  • this argument must be abstract data, in that case a file
  • for the rest of this function we will call the filename extrapol_generated_699 (formerly <anonymous>)"
  • the function has one system effect: reading from the file whose name was given as extrapol_generated_699 (formerly <anonymous> )
  • the function returns some abstract data, in that case data read from the file whose name was given as extrapol_generated_699 (formerly <anonymous> )

Now, chances are that we may want to use both functions. As it turns out, whenever a function has been analysed, Extrapol places the information it has deduced in its knowledge base (the environment) and may use it for further deductions.

Now, let’s feed the following additional source to Extrapol:

int main(int argc, char **argv) {
  assert(argc >= 1);
  int   fd  = do_open(argv[0]);
  char* buf = do_read(fd);
  free(buf);
  return 0;
}

In return, Extrapol will answer:

main: Function
        input arg argc         : "command-line argument" ()
        input arg argv         : "command-line argument" ()
        input vararg           : "command-line argument" ()
        effect                 : "read" (Identifier "argv" )
        effect                 : "open" (Identifier "argv", Constant "0" )
        return                 : Constant "0"
End

In other words, the effect of the full program will be to open and read from a file whose name was provided as a command-linen argument.

How does this work ?

For today’s entry, I’ll take that question with the meaning of “How do I use it ?” Well, it’s simple. Extrapol takes as input one or more C source files (they don’t have to be pre-processed) and a knowledge base of primitive functions. This knowledge base is an ASCII file with the same format as Extrapol’s answers.

For instance, to obtain the above demos, we provided Extrapol with the following piece of information for function malloc:

malloc: Function
  input arg size: Bottom
  return: Bottom
End

In other words, malloc is a function accepting one argument named size. Nothing special is expected from size and the returned value is compatible with any value.

Now, fread is a more complex function. Here’s the prototype of the function, as presented in its man page:

size_t fread(void *ptr, size_t size, size_t nmemb, FILE *stream);

For Extrapol, that’s a function with 4 arguments and a return value. Let’s start from the end.

• The return value could be anything, we won’t make any guarantee (that’s called Top — we could refine that).
• The last argument is a file. We’ve seen earlier how to deal with files, they’re abstract structures, which we’ve decided by convention to call "FILE"(foobar), where foobar is either the name of the file or a pointer to a variable/argument which contains that name. In that context, "FILE" is called a constructor, by the way. It’s just a character string which we use to differentiate abstract values. Correspondingly, foobar is the argument of "FILE".
• The second to last argument is a number of blocks to read. We’re just going to ignore it. In other words, that argument is compatible with any value. That’s Bottom.
• The second argument is a size. We’re also going to ignore it, so Bottom again.
• Finally, the first argument is an output argument — functionally, it’s a special form of return, so we’re going to mark that argument as output. We could just specify that it may contain anything and refuse to make any guarantee, but here, we’re going to refine a bit and specify that it’s abstract data, read from the file. Let’s call the constructor "data read from file" and give it as argument the name of the file. This gives "data read from file"(foobar).
• Oh, yeah, and before we forget, this function has a side-effect we’re interested in: it reads some content from that file foobar. Let’s call that effect "read"(foobar)

Or, in full Extrapol syntax:

fread: Function
   output arg ptr: "data read from file" ( Identifier "path" )
   input arg size : Bottom
   input arg nmemb: Bottom
   input arg stream: "FILE" ( Identifier "path" )
   return: Top
   effect: "read" ( Identifier "path" )
End

Now, from a set of C source files and this knowledge base, Extrapol will pre-process C, parse it, remove unused symbols then examine the source code and proceed by success deductions until either

• something goes wrong (typically, a function is used without being defined)
• every function has been examined.

Extrapol then outputs the result of his deductions, in a format fit for reinjection inside the knowledge base.

If you are curious, the theories behind this notion of deduction are

• lambda-calculus
• dependent types
• types with effects
• Hindley-Milner-style type inference.

This will be detailed further in another blog entry — and in a journal paper, whenever I find the time to complete it.

Does it work ?

The answer is yes, no and maybe.

• Maybe: testing on real applications is something yet to do. Currently, Extrapol works on our sample set, a set containing no entry larger than 100 lines. We’ll know more when we find the courage to test, say, tar or df.

• Yes: everything written above, and a dozen other samples, work.
• No: some features are not implemented yet. Function pointers won’t work, nor will recursivity. I haven’t put together the theory behind these constructions yet, so I don’t know yet how hard all of this will be. In addition, for the current prototype, we can’t deduce anything interesting on global variables yet, and functions need to be declared in the order in which they are used. These two aspects will be easy to fix, they just don’t have the highest priority.

How is it written ?

There are currently two different versions of Extrapol:

• Extrapol/Java is a Java-based implementation of the specification, by Steve-William Kissi, Bastien Jansen and David Teller. It is about 18,000 lines of code and, at this very moment, lags slightly behind the experimental version, Extrapol/ML.
• Extrapol/ML is the set of specifications, written in OCaml by David Teller — as well as the experimental version. It is about 3,000 lines of code, purely functional except for logging.

Both versions are meant as open-source, although the licence hasn’t been 100% decided. Extrapol/Java may end up MIT-style with Extrapol/ML ending up LGPL + linking exception.

Can I play with it ?

As soon as we’ve decided the licence, we’ll release the current prototypes. Ideally, this should happen before mid-June.

An updated version of the Lazy List module for OCaml has just been uploaded to Batteries Included and submitted to ExtLib. See the release notes for more details.

In addition, I am currently using this module to write a parser combinator library for OCaml. This library has reached early testing stage and will hopefully be added to Batteries Included soon.

I have made available the first preview of a second module for OCaml Batteries Included module: Enum. This module builds upon ExtLib’s enumerations (which it means to replace, if it is accepted upstream) and provides support for representation-independent iterators. These iterators are used pervasively in ExtLib and will also be used pervasively in the rest of Batteries Included, as a manner of converting data from/to data structures and as a base for syntax extensions.

With respect to ExtLib’s current implementation, this release adds

• numerous powerful constructors and manipulation functions
• functions inspired from SDFlow and dedicated to cooperative
• better management of infinite iterators
• better management of iterators created using from
• syntactic sugar.

As an example of the last point, let us note that it is now possible, without any Camlp4 extension, to replace for loops with a more (stream-)functional counterpart. That is, instead of

for i = 1 to n do
    (*...*)
done

one may now write

iter (fun i -> (* ... *) )
  (5 -- 10)

for an imperative loop or

map (fun i -> (* ... *) )
  (5 -- 10)

for a lazy transformation, etc. It won’t improve performance and it doesn’t look more readable at first glance, but it allows short expressions such as :

iter printf (5 -- 10) (*to print all numbers between 5 and 10*)
map ( ~ ) (5 --10) (*to obtain enumeration -5, -6, -7, -8, -9, -10 *)
fold ( + ) 0 ( 5 -- 10 )(*to sum all numbers between 5 and 10*)

etc. Everything is computed lazily, without allocating any intermediate data structure.

Code may be found here.

Ces jours-ci, je travaille beaucoup avec et sur OCaml, que ce soit pour le projet ExtraPol (dont je finirai bien par vous glisser quelques mots) ou pour Batteries Included (la rénovation en cours de la bibliothèque standard de OCaml). En particulier, je viens de finaliser un module de gestion des listes paresseuses. Paresseuses ? Oui, paresseuses.

Attardons-nous un moment sur le concept de paresse en programmation.

En Java (ou C++ ou C# ou …)

Presque tous les langages de programmation permettent, de manière restreinte, de définir des expressions paresseuses, c’est-à-dire des expressions dont le résultat n’est calculé que s’il peut influencer l’exécution du programme. Ainsi, en Java, nous pourrons définir la méthode isEquals suivante :

bool isEquals(Object x)
{
  return x && x.equals(myObject);
}

Ici, au cours de l’exécution de cette fonction, x.equals(myObject) ne sera ffectivement évalué que si x n’est pas null. Java définit ainsi trois opérateurs paresseux &&, || et ?: : dans chacun des trois cas, à l’exécution du programme, la première opérande est évaluée avant de décider que faire de la deuxième (et de la troisième, dans le cas de ?:). Ces constructions sont très utiles, mais sont loin de couvrir toutes les circonstances dans lesquelles la paresse peut s’avérer utile.

Ainsi, imaginons un instant que nous souhaitons écrire une bibliothèque de journalisation, dont le rôle est d’enregistrer des messages dans un fichier au fur et à mesure de l’exécution du programme. Ajoutons une contrainte : les messages ne doivent être effectivement enregistrés que lorsque le journal est activé, par exemple parce que l’utilisateur est en mode de débogage :

void log(String s)
{
   if(LOG) stream.println(s);
}

La méthode log sera typiquement invoquée des centaines de fois durant l’exécution du code, sous la forme suivante :

void myFunction(int i, int j, int k)
{
   myLog.log("Entering myFunction("+i+", "+j+", "+j+")");
   //...
   myLog.log("Leaving myFunction()");
}

Des centaines de fois, nous aurons donc besoin de calculer le résultat de "Entering myFunction("+i+", "+j+", "+j+")", soit trois conversions d’entiers en chaînes de caractères, 6 concaténations de chaînes de caractères et un gaspillage de mémoire vive que nous pourrions éviter lorsque LOG est false. Comment faire pour éviter ce gaspillage ? La première possibilité consiste à exposer la valeur de LOG à tout le programme et à laisser le programmeur écrire plutôt

void myFunction(int i, int j, int k)
{
   if(LOG) myLog.log("Entering myFunction("+i+", "+j+", "+j+")");
   //...
   if(LOG) myLog.log("Leaving myFunction()");
}

Malheureusement, cette transformation nous oblige à contaminer tout le programme avec ce champ LOG, au détriment de la lisibilité et de l’extensibilité. En C ou C++, on pourrait cacher ce LOG derrière une macro, cette fois au détriment du débogage, de la modularité et de la robustesse. En Java, si nous n’avons pas une telle possibilité, nous pouvons utiliser des classes anonymes pour arriver aux mêmes fins :

Commençons par modifier notre bibliothèque de journalisation :

public interface LazyString
{
   public String toString();
}

void log(Object s)
{
   if(LOG) stream.println(s.toString());
}

L’interface LazyString n’est guère contraignante : elle se contente de promettre que les objets qui l’implantent dispoent bien d’une méthode publique String toString(), qui servira à extraire de l’objet une chaîne de caractères. La différence avec ce qui précède est que nous pouvons nous débrouiller pour que la construction de la chaîne de caractères n’ait lieu qu’au moment où la méthode println est invoquée. En particulier, cette construction n’aura jamais lieu si LOG est false. Pour utiliser cette nouvelle version du journal, nous pourrons réécrire myFunction de la manière suivante :

void myFunction(int i, int j, int k)
{
   myLog.log(new LazyString() { public String toString() { return "Entering myFunction("+i+", "+j+", "+j+")" });
   //...
   myLog.log("Leaving myFunction()");
}

Est-ce la fin de l’histoire ? Pas tout à fait. Pour le moment, en Java, nous ne pouvons pas améliorer la syntaxe lors de l’appel de log — en tant que langage, Java est connu pour sa lourdeur syntaxique. En l’absence d’un préprocesseur digne de ce nom, nous ne pourrons rien faire de ce côté-là. Par contre, nous pouvons nous attaquer à un autre problème, qui se posera dès que nous serons confrontés à une méthode log à peine peu plus complexe :

void log(Object s)
{
   if(LOG_TO_FILE) file_stream.println(s.toString());
   if(LOG_TO_WINDOW) text_pane.out.println(s.toString());
   if(LOG_TO_STATUSBAR) statusbar.setText(s.toString());
}

Ici, s.toString() sera invoqué trois fois et calculera trois fois le même résultat. Pour un exemple aussi simple que le nôtre, ce n’est pas encore bien grave, mais on peut imaginer des contextes dans lesquels le calcul serait suffisamment long pour que ce délai soit inacceptable.

Qu’à cela ne tienne, il suffit de réécrire log de manière à retenir la valeur de s.toString(). Voire mieux, nous pouvons encapsuler tout ceci dans une classe plus générique :

public interface Result<T>
{
   public T getValue();
}
public abstract class Lazy<T>
{
   private boolean computed = false;
   private T value = null;
   /**
    * Proceeds to the actual computation.
    * This method will only be called once.
    */
   protected abstract T value();
   public final synchronized T getValue()
   {
      if(computed == false)
      {
        value       = value();
        computed = true;
      }
      return value;
   }
}

public abstract class LazyString extends Lazy<String>
{
   public String toString()
   {
      return this.getValue();
   }
}

En modifiant myFunction pour utiliser cette nouvelle version de LazyString, nous obtenons :

void myFunction(int i, int j, int k)
{
   myLog.log(new LazyString() { protected String value() { return "Entering myFunction("+i+", "+j+", "+j+")" });
   //...
   myLog.log("Leaving myFunction()");
}

Qu’avons-nous gagné ? Nous avons maintenant sous la main une interface Result<T> qui permet de représenter une opération. Si l’objet qui implante Result<T> est en fait un Lazy<T>, le calcul ne sera effectué que si son résultat est effectivement consulté. Si le résultat est consulté plusieurs fois (potentiellement par plusieurs threads différents), le calcul n’est toujours effectué qu’une seul fois.

Nous venons d’ajouter une dose d’évaluation paresseuse à Java.

Pour aller plus loin, regardons du côté de la programmation fonctionnelle — et des structures de données paresseuses.

Du côté de la programmation fonctionnelle

Commençons par réécrire en OCaml la première version de nos fonctions :

let log s = if should_log then output stream s

Nous venons de définir, comme en Java, une fonction nommée log, qui accepte comme paramètre un argument s — ici, une chaîne de caractères. Le contenu de la fonction log instruit d’écrire s sur un certain flux stream, si une certaine valeur booléenne should_log est vraie. Comme en Java, nous invoquerons cette fonction depuis my_function, à l’aide de :

let my_function i j k =
  log (sprintf "Entering my_function %i %i %i" i j k);
  (* ... *)
  log "Leaving my_function"

Jusque-là, à part les parenthèses et l’utilisation de la fonction sprintf, rien de bien différent. De nouveau, il est nécessaire de convertir i, j et k en chaînes de caractères et de procéder à quelques concaténations.

À partir d’ici, comme en Java, nous pouvons définir équivalent de Lazy<T>, que nous appellerions probablement 'a lazy, doté d’un constructeur qui acceptera en argument une fonction dont le résultat est un 'a, etc. La transformation de notre code pour convertir log en appel paresseux est globalement similaire à ce que nous ferions en Java. De fait, tout ceci n’est pas nécessaire puisque puisque la programmation paresseuse est en fait une primitive du langage. Le mot-clé lazy introduit une expression de type 'a Lazy.t, c’est-à-dire dont le résultat est de type 'a et ne sera calculé que s’il est nécessaire. La fonction force : 'a Lazy.t -> 'a permet alors de consulter le résultat d’une valeur ainsi mise en réserve, en la calculant au passage si nécessaire. De fait, notre version définitive ressemblera à

open Lazy
let log s =
  if should_log_1 then output stream_1 (force s);
  if should_log_2 then output stream_2 (force s);
  if should_log_3 then output stream_3 (force s)

let my_function i j k =
  log (lazy (sprintf "Entering my_function %i %i %i" i j k));
  (* ... *)
  log (lazy "Leaving my_function&quot  

Notons au passage qu’il ne serait pas possible de réécrire directement lazy sous la forme d’une fonction OCaml. Pour réinventer lazy, il serait nécessaire de passer par Camlp4 ou d’accepter des notations légèrement plus lourdes.

Et alors ?

Il va falloir que je vous avoue quelque chose : je me moque complètement de la fonction log. Dans la programmation paresseuse, le plus intéressant, c’est bien les structures de données.

Tenez, en Java, nous pouvons très bien redéfinir la notion d’itérateurs de la manière suivante :

public interface MyIterator<T>
{
  public Lazy<MyIterator<T>> next();
  public T value;
}

Un itérateur est ici un objet capable de contenir une valeur… et de renvoyer un autre itérateur, qui représente la suite de l’itération. On écrira de même en OCaml :

type 'a my_iterator = Iterator of 'a * 'a my_iterator Lazy.t

Complétons cette définition pour nous autoriser à construire des itérations finies :

type 'a node =
 | Nil
 | Cons of 'a * 'a lazy_list
type 'a lazy_list = ('a node) Lazy.t

Nous venons de définir la notion de liste paresseuse. Une liste paresseuse est une valeur paresseuse qui, une fois évaluée, produit soit le résultat Nil (la liste vide), soit un résultat de la forme Cons(h, t) où h est une valeur et t est la suite de la liste paresseuse.

À partir de cette définition, nous pouvons construire une fonction range, qui servira à représenter un intervalle d’entiers :

let rec range i j =
 if i >= j then Nil
 else            range (i+1) j

Ainsi, en OCaml, range 0 100000 calculera les nombres 0, 1, …, 100000 au fur et à mesure qu’ils seront demandés.

À partir de là, nous pouvons définir les transformations habituelles sur les structures de données. Ainsi, pour convertir (paresseusement) une liste paresseuse en une autre, comme pour les listes habituelles, nous pouvons définir la fonction map :

let rec map f l = match force l with
  | Nil            -> lazy Nil
  | Cons (h,t) -> lazy Cons (f h, map f t)

Cette fonction map, qui sera l’un des premiers outils que nous placerons dans notre bibliothèque de gestion des listes paresseuses, applique une fonction successivement à chaque élément d’une liste paresseuse, de manière à obtenir une nouvelle liste paresseuse. Pour doubler tous les éléments de notre intervalle précédent, nous écrirons donc

map (( * ) 2) (range 0 100000)

De la même manière, nous pouvons définir le nécessaire pour filtrer les éléments d’une liste afin de n’en garder que ceux qui vérifient une propriété donnée, le tout sous la forme d’une fonction filter, qui rejoindra map dans notre bibliothèque standard.

let rec filter f l = match Lazy.force l with
  | Nil -> lazy Nil
  | Cons(h,t) -> lazy (Cons (f h, filter t))

Et à ce prix-là, définissons une fonction iter, tout aussi standard, qui nous permettra d’appliquer une fonction impérative à tous les éléments d’une liste paresseuse, de la même manière que la boucle for de Python ou la nouvelle boucle for de Java :

let rec iter f l = match force l with
  | Nil            -> ()
  | Cons (h,t) -> f h; iter t

En combinant tout ce qui précède, nous pouvons faire afficher les carrés parfaits de l’ensemble des nombres pairs des nombres de l’intervalle [0; 100000].

let is_square x =
  let y = int_of_float (sqrt (float_of_int x)) in
  x = y * y

iter print_int (filter is_square (map (( * ) 2) (range 0 100000)))

Comme la liste n’est consultée qu’une seule fois, grâce à la magie de la paresse et du ramasse-miettes, tout ceci se fera fait sans avoir à allouer la mémoire vive nécessaire pour retenir tous les entiers entre 0 et 100000.

Jusqu’ici, toutes les opérations que nous avons vues auraient pu être implantées, peut-être avec quelques difficultés, en utilisant des itérateurs ou des générateurs, tels que ceux que définissent les bibliothèques Java, C#, JavaScript, Python, OCaml etc. Tout comme les listes paresseuses, les itérateurs et générateurs permettent de représenter des suites d’informations qui ne seront effectivement calculées que lorsqu’elles seront effectivement consultées. Mais à la différence des listes paresseuses, les itérateurs/générateurs oublient les informations immédiatement après les avoir fournies. Si les itérateurs et générateurs sont très utiles — et probablement plus optimisés que les listes paresseuses pour les exemples précédents — leur champ d’application s’arrête dès que les données peuvent être utilisées plusieurs fois.

Ainsi, considérons l’une des applications majeures des itérateurs/générateurs et des listes paresseuses : l’analyse de langages, et plus particulièrement l’analyse lexicale et syntaxique d’un code source. Le plus fréquemment, on commence par considérer le fichier d’entrée comme un itérateur/générateur de caractères. Un filtre, l’analyseur lexical, s’applique alors à cet itérateur pour le transformer en itérateur de lexèmes — c’est le rôle d’outils tels que Lex, Flex ou, aussi surprenant que cela puisse paraître, Sax. Ce deuxième itérateur est alors consommé par un analyseur syntaxique, dont le rôle est de produire un arbre de syntaxe abstraite, qui représentera le code source en mémoire vive — c’est, cette fois, le rôle d’outils tels que Bison, Yacc ou DOM. Ces derniers, ainsi que [presque tous] leurs concurrents, consultent à l’avance k lexèmes depuis l’itérateur de lexème, pour un certain k fixé lors de la conception de l’analyseur, émettent des hypothèses en partant de ces k lexèmes, et ne peuvent pas revenir en arrière, en cas d’erreur, de plus de k pas. À l’inverse, et de manière très schématique, les combinateurs de parseurs construits sur des listes paresseuses, tels que Parsec (pour Haskell) ou PLC (pour OCaml), ne sont pas limités par ces k lexèmes d’avance, puisqu’ils peuvent à volonté revenir en arrière dans la liste. Un élément ne disparaît de la liste paresseuse que lorsque sa valeur ne peut plus influencer l’exécution du programme. Cette conception à base de listes paresseuses se paye en termes de performances et de consommation de mémoire mais offre beaucoup plus de flexibilité, notamment la possibilité de construire ou de modifier dynamiquement des analyseurs syntaxiques.

Avant de conclure sur la comparaison entre itérateurs et listes paresseuses, précisons brièvement qu’il est aisé de construire l’un par-dessus l’autre : un itérateur est une liste paresseuse qui oublie ses éléments au fur et à mesure qu’ils sont consommés, alors qu’une liste paresseuse est un itérateur qui retient ses éléments jusqu’à intervention du ramasse-miettes. Ainsi, dans la bibliothèque sur laquelle je travaille, la conversion d’une liste paresseuse en itération s’est écrite, jusqu’à une récente optimisation :

let enum l =
  let reference = ref l in
    Enum.from (fun () -> match next !reference with
			 | Cons(x,t) -> reference := t; x
			 | Nil          -> raise Enum.No_more_elements )

Dans cet extrait de code, nous commençons par déclarer une variable modifiable nommée reference et qui désignera initialement le premier élément de la liste. Nous définissons alors une fonction anonyme qui, lorsqu’elle sera appelée, renverra l’élément actuel désigné par reference, ou, si nous avons dépassé la fin de la liste, lancera une exception Enum.No_more_elements pour signaler que l’itérateur est terminé. La fonction Enum.from construit l’itérateur dont le comportement est donné par cette fonction.

À l’inverse, pour convertir un itérateur en liste paresseuse, nous employons la fonction suivante :

let of_enum e =
  let rec aux () =
    lazy (match Enum.get e with
      |	Some x -> Cons (x, aux () )
      | None    -> Nil )
  in aux ()

Dans l’extrait, nous commençons par définir une boucle que nous nommons aux et dons le contenu est paresseux. À chaque fois qu’un nouvel élément de la liste est consulté, nous consommons la valeur du prochain élément de notre itérateur. Si celui-ci existe, nous l’appelons x, et ce x constitue le prochain élément de notre liste, tandis que la suite de la liste sera donnée par le résultat de la prochaine invocation de la boucle aux. Dans le cas contraire, la liste est terminée.

Références :

• Pour plus de détails sur la distinction entre générateurs, itérateurs et listes paresseuses, je vous invite à consulter Iterators: Signs of Weakness in Object-Oriented Languages, par Henry G. Baker.
• Pour plus de détails sur le module de listes paresseuses de Batteries Included, le code source est disponible sur OCaml Forge. Le code source du module Enum, qui définit des itérateurs pour OCaml, est disponible avec le reste de la bibliothèque ExtLib, sur Google Code.
• Pour plus de détails sur la programmation paresseuse en OCaml, le guide de référence est à votre disposition.
• Enfin, rendons à César ce qui appartient à César. Si l’évaluation paresseuse vous intéresse, vous êtes vivement encouragés à vous informer sur le langage de programmation Haskell, dans lequel toutes les évaluations sont paresseuses par défaut.