I recently read a news story (here) where a “tell-tale programmer” talks about the difficulties of developing games for the Wii.

He argues that the Wii’s lack of processing power & memory in comparison to contemporaries, Xbox 360 & PS3, make it extremely difficult to develop a game that can function on all three systems and stand up (in terms of quality) in it’s own right.

He even goes as far as to say that Apple’s iPhone is more powerful than the Wii itself. A contentious statement indeed!

This may be indicative of  software companies and developers slipping into the mindset that more power = better games.

Well, it makes games look nicer, for sure. But if better looks did, in fact, equal better games then most titles for the Xbox 360 and the PS3 would be outstanding. But the truth is, they aren’t.

In fact, some of them suffer from a lack of imagination and such severe shallow beauty they wouldn’t even make it as a member of Girls Aloud.

The formula for making better games is no secret and has been known for years. But, while keenly observed by some, it is often foolishly ignored by others; “better gameplay = better games”.

Ok, so if the iPhone actually ismore powerful a gaming platform than the Wii, then that’s fair enough, but power has never been a selling point for the Wii (or even an issue for most consumers) and to complain of its’ shortcomings in this area is to completely miss the point. Additionally, for a professional games programmer to complain about it is the equivalent of a bad workman blaming his tools.

First of all, the abilities and power of the top three consoles are very different, it’s not a level playing field and never has been. Nor should it be.

What the Wii lacks in power, it makes up for in innovation. What the Xbox lacks in innovation it makes up for in being the versatile all rounder. And, what the PS3 lack in versatility it makes up for in being cutting edge with it’s Blu Ray drive & HD options. The fact they’re different is crucial to their success.

Since Pong & Space Invaders first appeared there’s never been a time where gaming systems have been equal in terms of power or ability. You quite simply have to tailor your software to fit within the confines of the hardware’s abilities. If you don’t want to, then develop and build your own system and best of luck to you.

If it’s just raw power you want, there’s always a bigger fish, so to speak. And the biggest fish isn’t the biggest for very long. Even as recently as the Nintendo Gameboy.

The Gameboy was, on a purely technical level, the least powerful and least advanced of the competing handhelds of the time (SEGA’s ‘Game Gear, ATARI’s ‘Lynx’ and NEC’s ‘Turbo Express’). What stood it head & shoulders above those technologically superior machines were two important things;

1, software support - it had a ton of great games, and

2, it wasn’t the most extravagantly powerful or advanced handheld on the market so it was relatively cheap to make and priced competitively.

Complaining about a lack of power or memory in the Wii is like knowing you don’t like liquorice, eating it anyway and then complaining that it tastes like liquorice. Or, to put it another (more relevant) way, it’s like taking a hi res picture from your 15 megapixel camera and resizing for the internet at 72DPI - all about scaling and optimisation.

Nintendo have positioned the Wii in the marketplace masterfully. They promote it as a fun console, family friendly, appealing to the ‘casual’ gamer and is more interactive than sitting in front of the telly with a control pad. It sells because of innovation (or gimmicks, depending on your point of view), and fun. Not power.

In fact, it’s great that some developers (Nintendo included) still remember the old school mantra; ‘gameplay is king’ and are innovating ways to keep surprising us.

Now, I have nothing against the XBox or PS3, but no amount of full HD, photo-realism, swanky physics engines or fancy lighting/bloom effects (all of which could also be regarded as gimmicks, albeit next gen spangly shiny ones) can disguise a shoddy title and fool the gamer. After all, ‘you can’t polish a turd’.

Historically, limited hardware has always forced software developers who are willing to push the envelope to improve and innovate rather than just taking a rubbish game, tacking on some fancy bells & whistles (just because they CAN) then selling it based on appearance rather than merit or depth.

A good example of this is the recent ‘Ghostbusters’ game…

It looks great on every platform, but the Wii version was creatively simplified, giving it more of a cartoon appearance (like the old ‘Real Ghostbusters’ cartoon) so it would run well on that platform. One size does not fit all and that is the essence of good porting from a high end graphics platform to a limited or less powerful one.

Fueling this lazy ‘one size fits all’ approach to programming is the lack of any real platform-exclusivity anymore.

To make as much money as possible for the developer it seems every game has to be released on every platform and, as not all platforms are created equal, the results will vary if developers can’t be bothered to optimise their titles to play to the strengths of each system.

Back when you had to ask yourself the question ”Will I the NES or will I the Mastersystem?” or “Maybe the Megadrive… or will I the SNES?”, you faced a straightforward choice over what to expect from your console in terms of power and the games you had access to.

In-house (1st party) developers, like Nintendo’s and SEGA’s (back when they still built & sold hardware) have the luxury of being supported by the giant corporate structure of an established hardware manufacturer (albeit on with excellent reputations for games development) and can concentrate on quality rather than rushing out a title to keep debtors from the door.

External (3rd party) developers are much more time and money conscious. They have to focus more on commercial viability and getting a game developed, finished and on the shelves in time for busy buying periods (like Christmas) than unfeasibly long and deep R&D. As a result, quality often suffers and we end up with a glut of underachieving, over-hyped (and usually buggy) games on the shelves. Obviously this isn’t always the case as 3rd party developers have given us some awesome games recently (Bethesda’s ‘Fallout 3′ and Rockstar’s ‘Grand Theft Auto’ series), but the ratio of hits is disproportionately small when compared to the misses.

If you buy a PS3 now, I’m pretty sure there’s only a handful of games you wouldn’t be able to get on the Xbox, and even then (as with the case of Rockstar games’ ‘GTA IV’) most third party developers will eventually forego the ‘exclusivity’ privilege in order to sell more units. It’s basic business sense to sell you product to the most people as possible.

Unfortunately for the PS3 though, there’s no single game that is so good, only available on the PS3 and has enough appeal to the masses that those masses would buy the system just to play it. Of course, Sony (manufacturer of the PS3) are battling against their own uncharacteristically poor business decisions too. Instead of a regular (and comparatively cheap) DVD drive, they stuck in an expensive Blu-Ray instead.

Turns out nobody really wants this next gen drive if it costs 50% more than the competitor and thus they priced themselves out of the market. This is especially acute due to, as I mentioned earlier,  most games on the PS3 also being available on the cheaper (and far more popular & well supported)  X-Box.

Also, unlike the PS3, the X-box 360 (if you buy a hard drive for it) is backwardly compatible with (most of) your old games from the original X-Box so you don’t have to start your (expensive) games collection off from scratch again.

Then there’s the ‘killer app’ phenomenon. Or, in the PS3’s case; the killer app ‘problem’.

A ‘killer app’ is slang for a game that is so good people will buy whatever system it’s on just to play it and, try as they might, Sony just haven’t got one for the PS3.

Examples of killer apps for previous Playstation generations were the ‘Metal Gear Solid’, ‘Resident Evil’ and ’Gran Turismo’ franchises.

They were not only exclusive to the Playstation but they were so good they were games to buy a Playstation for (killer apps). That seems to have changed this time though as the latest Metal Gear game, ‘Guns Of The Patriots’, while a critical success among hardcore game journalists and similarly hard-core gamers, had its’ initial fire of excitement doused by heavy criticism from non-hardcore franchise fans and the more general gaming media about there being more expositionary cutscenes than actual gameplay (in perhaps another case of programmers making things beautiful rather than fun).

Indeed, the game presents around 30 minutes of relentless opening cinematics before you actually take control and ‘do’ something when first starting to play the game. This kind of detachment from the experience may provide plot and drama but it also removes you from having an active role in the game. Not the kind of game to just pick up & play.

Similarly, Gran Turismo (while an excellent driving simulator) is really not a mainstream game either. To get the most out of it, you need to tinker with your car’s mechanics so much you may as well just study mechanical engineering in real life and make some decent money in F1 instead of staring squinty-eyed at your TV adjusting the slip diff (whatever that is) another few millimetres (if that’s even how you adjust it) to take corners better.

Resident Evil, while it may have started life as a Playstation exclusive, is now selling itself to anyone with a console and a pad. It’s also a great example of how game programmers took an existing game and developed it specifically for the Wii by implementing a fantastic control system unique to the system. It then sold bucketloads. Just shows you what brains can do when brawn is out of the equation.

When a genuine killer app does come along (e.g the aforementioned Grand Theft Auto) exclusivity only benefits the hardware manufacturer as the software developer can’t sell across multiple platforms and thus limiting their audience significantly.

The best killer apps can determine a console’s success or failure. It may already be too late for the PS3 as sales figures continue to underwhelm and maybe the only good thing to come from it will ultimately be a very hard (and expensive) lesson about how not to sell consoles in future.

As an example of the ‘killer app’ in action, the reason I wanted a SNES back in 1992 was because of Super Mario World, the reason I bought an N64 in 1998 was because Goldeneye came with it, I bought a Playstation because of Resident Evil and a Gameboy in the early 90’s because of Tetris.

The original X-Box had Halo & Halo 2. Those games were so huge and well received that when Halo 3 was announced for the X-Box 360, parting with the cash for the new console became an easy decision for gamers (established and newbies); it was just a means to an end in order to play the latest in the series of a smash hit first person shooter. Indeed, it was so huge on launch day that it made news all over the world and many shops had midnight openings to cater for demand.

Now, all this talk of good games determining the success of a console may seem like a tangent that’s moved far away from the original point of this piece (and, to be honest, it kinda is), but if ‘good games maketh the console’ then ‘good gameplay maketh the game’. And this is what it all comes back to; developers complaining about not enough power from the Wii to make the games good enough.

So, to get back to this original point in the form of a metaphor, would the Ford car company complain about having to design a different engine for a Fiesta after they’ve finished the engine design for the Focus Coupe Cabriolet? Of course not. There’s already the understanding that each model, no matter how powerful needs it’s own engine and that engine is specific to the model operating well within it’s class.

Instead, this ‘tell-tale programmer’ has made that Coupe engine, shoehorned it into the Fiesta with little regard and now blames the Fiesta when its’ gearbox, clutch and suspension can’t handle it.

As a consumer, we make a choice whether to buy the Coupe or the Fiesta. That choice will probably come down to a matter of budget, expectation and preference. What we expect regardless though is good performance whatever road we drive it on. I don’t expect to buy a Fiesta and then discover I can’t drive on the motorway because the engine is too small.

If a software company made the decision to develop games then whatever system they develop for will have limitations. So, instead of doing a bad job then blaming the system for not handling it properly, do it right so the system can run it or don’t do it at all.

If the Wii can’t handle it then don’t release it.

Although, before complaining too much, maybe take a look at some of the excellent Wii games that don’t seem to struggle with the hardware to produce fantastic results.  Start with Super Mario Galaxy, Guitar Hero, Zelda, Super Smash Brothers, Resident Evil 4 & Lego Star Wars.

Maybe the lure of a lucrative cross-platform cash-in is too much to resist sometimes, but if games that were previously fine on other systems are ruined and your reputation goes downhill along with it, why bother?

Our midmornings, afternoons, and even nites are filled with dozens of cooking shows on  our cable channels… and we  are only talking about  presented from Pakistani channels…. we also  have to take BBC, andother food network type cooking shows…. There is a long list of hosts which are good at cooking and were known lready before this trend started  on tv ,like Rahat on Geo, and Mehboob, andZakir  etc…

 However most of   these people you will see answering live calls from remote towns    for  ingredients  or   to praise…some cooking  shows   are promoting healthy food rest is only focusing on …   Food. . apparently they have too much air time available … will see whole dish prepared in front of you…. there is no time restrictions to use elasped time or double dishes to show whole thing finished…

Since private TV channels  are on the boom cooking show are a must feature on all of them. Youwill find every type of  personalities cooking in front of camera , with lots of oil ads  and  pretty anchors.

Shows like cooking with Chef Rahat , or Shai kicked the host out,   these ladies take live calls and cook too.From biryani to Pizza and cake to dal they have every recipe in their sleeve.

Guys are not behind  in this matter. We  are actually pleasantly surprised  to see Pakistan men, trying to cook and be good at it. It seems like a good trend for our  Nation where men  usually don`t get up to get their own glass of water. Chef Zakir, and Mehboob are the most popular among ladies.There this one new programme where they are focusing on desserts , which seems  very useful.

There are two whole  channels devoted to cooking by the name of “Masala Tv” and “Zauq”.After morning shows you will find chefs on every channel,  and on exclusively  devoted  to food channels too.

How ever there are two things  which are very  confusing… They do not  taste  what they cook, even their anchors do not try tasting after cooking  is done, which is very  unnatural. Is it some type of Desi conduct ? Code?  At the time of so much modrenity, it is hard to understand that they don’t show natural  behaviour.

Other thing is they take too much time in live cooking, one can use some things half ready and get on with a dish… but usually they  spend as much time on screen ,as they actually would do in  their  own kitchens. This is the luxury only TV in Pakistancan provide due to   high ratio of ads. You will see  kids acting like helpers too in  shows  on Wikkid.

At time we seem to lose track of ” Talk Shows” every Pakistani Tv channel is presenting. If we leave the Serious debate programmes aside , only morning shows are a long list… from our out spoken Nadia k to Amber w, and Amna, and Ghazal S, then Shaista W and list goes on… They all run for almost 2 hours and usually compete to blabber most. Thanx to Nadia khan , now it is a trend that you have to be yourself on tv `s expensive airtimne and you playing cute all nation have to take. They all have to be funny and witty and have to ask personal and irrelavent question to their guests. Ratio for women anchors is amazingly high, even established actresses interviewing serious politicians.Marinma k, to Nadia J, and Atiqa O, zQ all joind this band wagon. Then there are “Golden girls” who are most hard to swallow.
- Why can`t we keep a balance, between being modren, liberal and being fair we should not try to sell every thing with a pretty face.
- Or on the otherhand some will try to throw paint on billboards and try to ban Tv at once.
- People should get to be anchors, or producers on their special ability to conduct their jobs , on merits, not on their glamour and being a known face .
- This is a kind of reverse discrimination.

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.

A quick note to inform that I have made available the first preview of a module for OCaml Batteries Included module: Lazy Lists for OCaml. This module adds the ability to manipulate lists composed of elements which are only computed whenever their value is first needed. In particular, such lists may be used as a more powerful replacement for streams — or to port interesting algorithms from Haskell.

Code may be found here.