[Caml-list] If ou Pattern-matching ?

["Diego Olivier Fernandez Pons" <FernandezPons@iFrance.com>]

Je reconnais être un peu borné, j'applique en effet sans réfléchir
certaines recommandations de Pierre Weis (Conseils de programmation
Caml) : « On n'aura jamais peur d'abuser du filtrage ! » mais aussi
« Programmer simple et clair avant tout »

La question (soulevée d'ailleurs par Rémi Vanicat) est celle de
l'équivalence des codes suivants :

  let somme = function
    | 0 -> 0
    | k -> k + somme (k-1)
  ;;

et

  let somme = function n ->
    if n = 0 then 0
    else (k + somme (k-1))
 ;;

Employons donc la méthode proposée par Le Fessant : éxagérons !

let conditions = function
  | (0, 1, 1, 1, _) -> 1
  | (1, 0, 0, _, m) -> m
  | (1, 1, 0, L, 0) -> 1
  | (i, j, 0, L, m) when (i = j) && (L = m) ->  0
  | _ -> 1
;;
(Je n'ai pas écrit 30 cas mais l'idée y était)

Exercice 1 : réécrire ce code avec des « if then else »
Exercice 2 : répondre à la question « lequel des deux codes est le
plus lisible ? »

Fabrice Le Fessant à écrit :
< Tu fais du pattern-matching hyper-simple (deux a trois cas sans
< liaison) qui serait probablement cent fois mieux traite par un "if",
[...]
< Ce n'est pas le programmeur qui s'est planté, c'est celui qui
< lui a appris qu'il fallait utiliser un "match" là où il aurait dû
< utiliser un "if".
[...]
< Essaie donc de faire du pattern-matching avec 30 cas

Le filtrage est-il une alternative acceptable aux enchaînements de «
if then else » ? A mon avis oui car il est nettement plus lisible,
présente les informations de manière compacte et immédiatement
compréhensible. Cela minimise les risques d'erreur, réduit la longueur
des programmes, en facilite la maintenance, etc.

Encore un extrait des excellents conseils de Weis
< Au-delà d'une page, on se perd dans le code, l'indentation est peu
< lisible et difficile à maintenir correcte.
Le code avec filtrage que je présente assure :
 - une indentation uniforme (ce qui ne serait pas le cas avec des if)
 - une compacité qui ne nuit aucunement à la compréhension
Il est vrai qu'il est plus lent (on peut regrouper des cas avec if)

Les questions suivantes sont « dans quelle mesure il faut-il calquer
les fonctionnalités du filtrage sur celles de "if" ? » « Comment
concilier les éventuelles incompatibilités introduites ? » « Est-ce
bien raisonnable ? »

  i) il est évident qu'on ne pourrait pas se passer du filtrage avec
liaison, comment écrire sinon
    let longueur = function ->
       | [ ] -> 0
       | (_ :: reste) -> 1 + longueur (reste)
   Cette question est donc réglée, il n'est pas question d'éliminer le
filtrage avec liaison

  ii) quelles différences entre un filtrage et un « if then else » ?
      - le « if then else » permet la comparaison avec des valeurs
précédemment liées
      - le filtrage masque les valeurs précédemment liées

  Proposition :
      - introduire une seconde version de filtrage sans liaisons qui
serait identifiable par une syntaxe particulière (j'ai proposé match
mais ce peut-être autre chose si cela casse du code) et permettrait la
comparaison avec des valeurs précédemment liées.

  Critiques :
      - c'est compliqué à expliquer aux programmeurs (Maranget)
      - cela rompt l'unité conceptuelle du filtrage (Maranget)
      - c'est compliqué à introduire dans le compilateur (Maranget)
      - égalité structurelle ou égalité physique ? (Fernandez Pons)
      - tout le monde est heureux dans la vie sauf toi (Le Fessant)
      - tu serais incapable d'écrire un compilateur Caml (Le Fessant)
      - apprends la sémantique des constructions Caml avant de les
utiliser (Le Fessant)

  Réponse :
      - cela permet d'éviter certaines constructions douteuses
      - le filtrage actuel fait déjà des égalités avec les constantes
      - les nombreux messages des débutants sur cette liste, les
multiples avertissements dans le manuel montrent que la version
actuelle du filtrage n'est pas si intuitive non plus

  Critiques :
      - on peut toujours obtenir du code robuste en évitant les
constructions douteuses (Maranget)
      - on peut modifier le compilateur pour qu'il affiche un warning
idoine (Maranget)

   Réponse :
      - le langage devrait aider le programmeur à coder facilement des
programmes robustes et lisibles
      - on peut adopter une position flexible (ne pas obliger le
programmeur à utiliser cette nouvelle syntaxe)

Annexe : j'ai fait d'autres propositions (liaison dans le filtrage
avec les variables n'apparaissant pas précédemment) mais elles
introduiraient plus de difficultés qu'elles ne résolvent de problèmes.

Commentaire : si la locution « pattern-matching » vous hérisse, je
peux dire plutôt que je propose l'introduction d'un « multi-switch »
qui serait bien utile.

  iii) Est-ce bien utile de faire tout ce tapage, des modifications à
la sémantique du langage, etc. pour une « amélioration » aussi
insignifiante et qui a plus de conséquences que je ne semble croire ?

A cette question je ne puis répondre, c'est pour cela que je vous
écris. Comme le signale à propos Le Fessant, je me suis jamais
distingué par une connaissance approfondie du code source du
compilateur Caml, ni par ma virtuosité au maniement de la sémantique
du langage.

        Diego Olivier




-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr