The wait is over, Ronin 0.2.3 (code-named “faster”) has finally been released. This release contains new code, more specs, some very important architectural changes and a few bug-fixes.

Ronin on Ruby 1.9.1

Probably the most important news in Ronin 0.2.3, is that Ronin is now Ruby 1.9.1 compatible. Ronin can now take advantage of the considerable performance improvements in Ruby 1.9.1-p0. If you tend to do security research and find yourself having to use Ruby 1.9.1, you should look into using Ronin.

Faster Load-Times

Ronin also saw various architectural changes to help reduce load-times. The ronin/models.rb file was removed, which loaded models from the other Ronin libraries before the Database was setup. Now other Ronin libraries can call the Database.update! method, which will run non-destructive auto-migrations on the Database. Ronin::UI::CommandLine saw yet more refactoring. With the new Ronin::UI::CommandLine, sub-commands are loaded on-demand, instead of all at once.

Together these architectural changes have dramatically improved the load-time of Ronin’s console. On systems that rarely run the Ruby interpreter, start-up times for Ronin should look like the following:

$ time (echo exit | (ronin > /dev/null))

real	0m3.841s
user	0m1.141s
sys	0m0.514s

On systems that regularly run the Ruby interpreter (thus caching frequently used memory and data) start-up times for Ronin will be a little quicker:

$ time (echo exit | (ronin > /dev/null))

real	0m1.656s
user	0m1.137s
sys	0m0.478s

New Convenience Methods

In 0.2.3 the IPAddr#each and IPAddr.each methods were added. It’s somewhat common to need to iterate over a range of IP addresses. Say you have a CIDR notation IP address, and need to iterate over every IP address covered by it’s netmask. Simply create a new IPAddr object and call each:

ip = IPAddr.new('10.1.1.1/24')
ip.each do |addr|
  ...
end

Well that’s sort of cool, but what if you have a globbed IP address, similar to the ones nmap accepts? IPAddr.each has you covered:

IPAddr.each('10.1.1-5.*') do |addr|
  ...
end

Both IPAddr#each and IPAddr.each can iterate over IPv6 addresses.

Net.http_powered_by and Net.http_server also got added in 0.2.3. These methods provide quick access to the X-Powered-By and Server HTTP headers, respectively.

Net.http_powered_by(:url => 'http://www.stalkdaily.com/')
# => "PHP/5.2.9"

Net.http_server(:url => 'http://www.darkc0de.com/)
# => "Apache/2.2.11 (Unix) PHP/4.4.9 mod_ssl/2.2.11 OpenSSL/0.9.8c mod_fastcgi/2.4.6 Phusion_Passenger/2.1.2 DAV/2 SVN/1.4.2"

String#pad was also added in 0.2.3. The pad method doesn’t do a lot, it merely pads a String out to a maximum length:

"hello".pad('A', 48)
# => "helloAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"

If you hate having to deal with exceptions in Ruby, the try method might prove useful. The try method simple attempts to run a block of code, catching and ignoring any exceptions that were raised:

require 'resolv'

try do
  Resolv.getaddress('might.not.exist.com')
end

Cacheable

Ronin::Objectify was replaced by the new Ronin::Cacheable module. Cacheable provides reliable caching and loading of Contextified objects with Ronin’s Database. Using the new Cacheble module, the data you want cached into the database must be defined in a cache block:

ronin_exploit do
  cache do
    self.name = 'stupidhttpd'
    self.version = '0.2'
    self.author(:name => 'Postmodern')
  end

  ...
end

The use of a cache block creates a separation between the data to be cached and the code which will eventually be loaded.

Overlays

As of 0.2.3, overlays now support the automatic loading of the lib/init.rb file. So if you have code you’d like automatically loaded (maybe extensions to the Array class) from your Overlay, simply require it in the lib/init.rb file.

The loading of Extensions from Overlays became a little more robust in 0.2.3. If an exception is encountered when loading an extension file, the exception will be printed and the file ignored.

It has landed

The first alpha version of OCaml Batteries Included has landed. It is now available as source code, from the Forge or as a GODI package. You may find the API documentation here and the complete documentation there.

Remember, this is alpha-level code, use at your own risk. Also note that documentation generation is very slow (10+ minute on my laptop), so don’t worry if installation seems to last forever, it’s nearly true but not quite.

Reviews, comments, suggestions and bug reports are particularly welcome. We have a few trackers for these, as well as a forum, so don’t hesitate to use them. We’re also looking for volunteers to give us a hand, so please consider stepping forward.

What is OCaml Batteries Included?

Twenty years ago, a language was just a compiler. You could measure the quality of a language from the beauty of its semantics, the clarity of its syntax, the speed of generated code. That was then. In the meantime, the Java and .Net nuclear plants have been built, while the Python and Ruby communities have gradually developed their own powerhouses. All these platforms have amply demonstrated that a language can only be as beautiful, clear and fast as the libraries which developers are actually going to use for their work. In other words, it’s not about the language anymore, it’s about the platform.

At this point in time, out-of-the-box, OCaml isn’t a usable platform. There is no Unicode, there are no modern user interface toolkits, no distributed programming infrastructures, no network services, no type-safe communications, no analysis of other languages, no interfacing with industrial platforms, no XML, non modern two- or three-dimensional drawing engine, etc. This would not be too much of a problem if OCaml provided an easy way of installing new libraries and of using these libraries once they are installed. This would also not be too much of a problem if OCaml could somehow guarantee that trivial data structures didn’t need to be reinvented by most projects and that communication between libraries happened lawlessly.

So no, out of the box, OCaml isn’t a usable platform. However, no matter what you’re trying to do, chances are that the community has already developed or adapted a tool to make your life easier. Easy installation of OCaml packages is quite possible, if you are using Debian or Ubuntu (apt-get), Fedora or Red Hat (yum) or actually, any Unix-compatible platform, including MacOS X and Windows (GODI). Simple and reliable usage of installed libraries can be done with Findlib. A comprehensive Unicode library is available (Camomile), as well as a modern user interface toolkit or two (LablGtk, OCamlRT), a number of distributed programming infrastructures (OCamlMPI, BSML, Opis, Camlp3l, OCamlNAE), libraries to interface with industrial platforms
(OCamlJava, SpiderCaml …), to analyse other languages (CIL, Dalton/FlowCaml, …), to read or write XML (PXP, Expat, …), to draw in two or three dimensions (Cairo, OpenGL), to test your programs (OUnit), etc. OCaml even offers a built-in tool to customize the language itself (Camlp4).

What’s missing? A few things. For now, not all important libraries are available as simple-to-install packages. That problem is being addressed by the devoted packagers of Debian, Fedora and GODI, while the possibility exists that the recently announced Symbiosis will also help address the issue. The other missing part is a standard set of libraries, language extensions and data structures which developers could be assured to find on every OCaml installation, and which would let them write programs without having to endlessly reinvent the same basic wheels, and without spending their time writing adapters between libraries which should work well together but don’t use the same conventions. OCaml Batteries Included is one possible answer to this problem.

OCaml Batteries Included consists in

• A core set of libraries, designed to define the basic standard data structures. This set, largely based on both the Base library of OCaml and ExtLib, extends the basic strings, arrays, lists… provided with OCaml and introduces numerous data structures, including enumerations, lazy lists, extendable inputs
  and outputs, dynamic arrays, unicode ropes…
• A uniformization layer, the glue, on top of chosen existing libraries. Note that we are not forking any of these libraries, only providing an additional layer on top of them.  The libraries may be installed manually by the user or, preferably, by automatic dependency resolution thanks to apt-get, yum, GODI or some other packaging tool. The uniformization layer serves to guarantee that libraries play together nicely, that only one manner of reading from a file or writing to the output is necessary, that every data provided by a library may be decoded by another, etc.
• Additional documentation on whichever library for which we provide glue, including both low-level documentation (“what the heck does this function do?”), mid-level documentation (“why should I use that function?”) and high-level documentation (“ok,I’m new here, where do I start?”)
• A handful of language extensions, provided as Camlp4 modules, to solve common issues, automatically generate boilerplate code, improve readability, …
• In the future, possibly a set of external tools.
• Build tools to make all of this transparent.
• And, of course, a logo.

(Batteries courtesy of Benjamin Pavie, Camel courtesy of John Olsen, no animals injured)

OCaml Batteries Included is a project maintained by the community, which means that it depends on you. If you have ideas, suggestions, complaints, bug reports, if you want to participate, to write code, documentation, tutorials, build tools, review code, have a word in policies, if you want a package to be included in the Batteries, or just to contact us, please visit our website and take advantage of our bug trackers, request for features trackers, forums, etc. (courtesy of OCaml Core). We can also often be seen on irc, on server freenode, channel #ocaml and, of course on the OCaml Mailing-List.

OCaml Batteries Included is also a work-in-progress. The version you have in front of your eyes does not contain everything we want to put in it, nor even all the code we have written for it. But we’ll get there. We intend to integrate additional libraries progressively, from minor release to minor release, with major milestones approximately twice per year. This policy is not written in stone and is largely subject to debate, so don’t hesitate to comment on the subject.

For more informations on the contents of OCaml Batteries Included, follow us towards the manual.

Relations to other libraries

Project Gallium’s Base Library

First, a word on vocabulary. We call “Base library” the library provided by INRIA with the default distribution of OCaml. We don’t call it “standard library” for the simple reason that there are several libraries vying for the status of standard, including Batteries Included.

The relation between Batteries Included and the Base Library is simple: the Base Library is one of the libraries for which Batteries Included provides a uniformization layer. We are not forking the library, merely providing additional functions, additional documentation, boilerplate code…

The complete Base Library is available in Batteries Included as module Legacy. Most modules are also available inside the Batteries module hierarchy, sometimes under different names, and usually completed by numerous new functions. A few modules are considered obsolete and appear only in Legacy.

Jane Street’s Core

Jane Street’s Core is another library vying for the status of standard, this time produced by Jane Street Capital. This library is comparable in purpose and design to the core of Batteries Included (actually, we draw some inspiration from them and we hope that they are going to draw some inspiration from us, too) but there is no code shared between Batteries Included and Jane Street’s Core for the moment.

In the future, Batteries Included may depend on Jane Street’s Core. This is not the case yet as, according to one of Jane Street’s Core’s authors, this library may change quite a lot, and in what we understand as possibly incompatible ways, before reaching version 1.0.

We already depend on two components of Jane Street’s Core: Type-Conv (a general infrastructure which may be used to generate boilerplate code) and Sexplib (an instance of Type-Conv used to generate code for serializing to/deserializing from human-readable S-Expressions). We intend to extend this to a third component of Jane Street’s Core: Bin-Prot, another instance of Type-Conv, used this time to generate serialization to/from binary protocols.

ExtLib

ExtLib is another extension of the OCaml Base Library. ExtLib was designed as a relatively small addition, with the idea of fitting nicely within the OCaml Base Library. Since 2005, ExtLib has essentially stopped growing, following a conscious choice from the maintainers.

OCaml Batteries Included is largely based on ExtLib. Indeed, the core of Batteries is essentially a fork of ExtLib. We intend to maintain  ascending compatibility with ExtLib (with the exception of changes in module names), although we have added a great number of features,  fixed bugs, split code, etc. For most purposes, OCaml Batteries Included contains ExtLib and, in our mind, superseeds this library. We hope that the maintainers and developers of ExtLib will consider migrating to OCaml Batteries Included and helping us with their skills.

Community OCaml

Community OCaml is an attempt to turn OCaml into an out-of-the-box complete development platform, including numerous libraries.  We have joined forces with the developers of Community OCaml and we share most of our code. Although the design of Community OCaml is not completely decided yet, it is quite possible that this will end up as distribution consisting in OCaml + Batteries Included + some package manager.

OCamlNet

OCamlNet is an implementation of numerous Internet protocols for OCaml, along with so many utilities that it almost constitues a complete general-purpose development library for OCaml.

OCaml Batteries Included will depend on OCamlNet and incorporate OCamlNet into its hierarchy. In particular, for the moment, OCaml Batteries Included provides little in the way of libraries for interacting with the operating system, as we intend to use OCamlNet for that purpose.

Caml Development Kit

The Caml Development Kit, or CDK, was another attempt to build a development platform around OCaml by bundling together OCaml itself and a number of interesting libraries and tools. By opposition to Batteries Included, this was a monolithic distribution, with a custom compiler and very little documentation. Development on CDK seems to have died around 2001.

There is no relation between CDK and Batteries Included other than the common goal. Any feedback from former CDK users or developers will be welcome, though.

GODI, Apt, Yum

GODI, Apt and Yum are the three main package managers available for OCaml users. The first one is OCaml-specific, the second one lives in Debian/Ubuntu/Knoppix world and the third one in the Red Hat/Fedora world.

OCaml Batteries Included has no direct relation with either package manager, nor does it replicate the work of any of these managers. However, as Batteries relies on numerous external libraries, use of a package manager is strongly recommended.

Findlib

Findlib is a compile-time package manager for OCaml. It lets developers easily specify which libraries are required and manages compile-time dependencies between installed libraries.

OCaml Batteries Included uses Findlib extensively.

Comparable projects, somewhere else

Python Batteries Included

To the best of our knowledge, the term “Batteries Included” was first coined by the Python community to describe the standard distribution of Python, which in addition to usual data structures, contains modules for handling databases, compression, a number of file format (de)coders including JSON, (X)HTML, XML, CSV, cryptography, logging, text interfaces, threading, inter-process communication, implementation of client and server protocols from SMTP to HTTP, communication with external webbrowsers, image and sound manipulation, internationalization, lexing and parsing, graphical interfaces, unit testing, sandboxing, reflexivity, OS-specific services, …

This massive number of out-of-the-box features, along with the conciseness of the language, are probably the two main reasons of the success of Python: simple tasks, even those which require complex libraries, may often be programmed with only a few lines and in a few minutes.

Well, obviously, we’re trying to provide something as useful with OCaml Batteries Included, but with the added safety and speed of OCaml.

Haskell Batteries Included

The Haskell Platform (although known as “Haskell Batteries Included”) is a recent project undertaken by the Haskell community with objectives comparable to OCaml Batteries Included: “provides a comprehensive,
stable and quality tested base for Haskell projects to work from.” At the time of this writing, the Haskell Platform has not released any software, although a first release is expected within a few weeks.

As OCaml Batteries, the Haskell Platform is community-led and relies on a number of decentralized libraries. As OCaml Batteries, the Haskell Platform requires package management.There are a number of differences in the methods, though.

Some differences are probably trivial: where we strive to work with any of the major package management systems, the Haskell Platform is based solely on Cabal, which may allow them a better integration. Where OCaml Batteries attempts to reclassify existing libraries into one uniform hierarchy of modules, the Haskell Platform keeps the original module names, as decided by their original authors, pre-Platform.

Others are quite far-reaching: OCaml Batteries provides an extended core of libraries to serve as support for standardization and uniformization, while the Haskell Platform doesn’t. Similarly, the Haskell Platform doesn’t add any uniformization layer, which means that the task of getting libraries to work together lies upon the end-user. Some Haskell libraries may be patched into compliance and uniformization, but this is not always possible, short of creating cyclic dependencies between libraries which should work together but don’t. Finally, the Haskell Platform has much stricter guidelines regarding libraries which can or can’t make it into the Platform. This is a good thing if library authors are willing to fix whichever problems prevent the inclusion of their work — something which we don’t assume for OCaml Batteries, at least not yet.

Despite these differences, both projects seem based on solid foundations. And hopefully, both will achieve large success.

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.

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

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.