Re: [Caml-list] Pattern matching

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

An english abstract follows

< Je coupe un example de syntaxe bizarre, sur la base de ce qu'on peut
< écrire de mauvais programmes dans tous les langages.
< Je trouve plus intéressant de chercher à définir un style de bonne
< programmation.

Mon « argumentation » consiste à exhiber de mauvais programmes car je
considère qu'un « bon » langage ne doit pas laisser un mauvais
programmeur faire du mauvais code (dans la mesure du possible). Quand
je dois passer trois heures à relire le code d'une tierce personne et
que je me rends compte que l'erreur est dûe à la fonction suivante :

let f = function n ->
   let g = function
     | (n, i ) -> ...
      ^^
car le programmeur a cru que n était déjà liée (l'exemple est un peu
exagéré mais bon...), j'ai tendance à taper (sans doute à tort) non
sur le programmeur mais sur le concepteur du langage.

< Sans rire c'est exactement ce que je recommanderais, non pas au
< concepteurs du compilo, mais aux programmeurs, surtout débutants
< (et d'ailleurs j'ecris généralement dans ce style).
Mais ??? ce code ne marche pas ! (n n'est pas lié)

Je vais vous dire des choses que vous n'ignorez pas au sujet du
pattern-matching, mais au moins serons nous clairs.

Il y a deux usages du pattern-matching :

le filtrage structurel (qui exige unification avec le motif et liaison
des variables)
  let somme = function
    | [] -> 0
    | [x] -> x
    | [x ; y] -> x + y
    | _ -> 0
  ;;

le filtrage de valeurs qui correspond à un « if then else » en plus
compact (et sans introduction de nouvelles variables)
  let delta = function
    | (0, 0, 1) -> 1
    | _ -> 0
  ;;

Ce dont je me « plains » est que la syntaxe actuelle de OCaml ne
différencie pas clairement les deux et permet des mélanges qui peuvent
donner lieu à du code douteux, à des erreurs difficiles à détecter...

let somme = function n ->
   let rec sommeCPS = function
      | (total, k) when (k = 0) -> total
      | (k, total) -> sommeCPS (total + k, k - 1)
         ^  ^^^
  in
       sommeCPS (0, n)
;;

Ici on est en train de filtrer des valeurs, donc d'après moi il ne
devrait y avoir qu'une seule liaison des variables total et k (et
j'estime que la syntaxe doit forcer à ce que ce soit le cas). Il
suffit d'une fonction interne un tant soit peu plus grande pour
que cette erreur soit difficile à voir.

Une rigidification de la syntaxe qui permet d'éviter des erreurs
(communes comme le prouve le nombre des messages de débutants sur ce
sujet, la mise en garde dans le manuel...) est d'après moi
parfaitement justifiée. Et puisqu'il y a deux syntaxes équivalentes
(une avec match with explicite, l'autre sans), je proposais que :
 - la syntaxe « match with » soit réservée au filtrage de valeurs
 - l'on puisse utiliser des variables précédemment liées dans le
filtrage de valeurs (puisqu'il n'introduit pas de nouvelles variables)
 - laisser le filtrage de structure tel qu'il est (et donc
l'unification avec le motif, autrement dit les variables liantes)

Je conçois cependant que l'on puisse ne pas être d'accord à ce sujet.

        Diego Olivier

There are two kind of pattern matching :

i) structure matching
  let add = function
    | [] -> 0
    | [x] -> x
    | [x ; y] -> x + y
    | _ -> 0
  ;;

ii) value matching
  let delta = function
    | (0, 0, 1) -> 1
    | _ -> 0
  ;;

mixing both allows mistakes that could be sometimes very hard to find
let add = function n ->
   let rec addCPS = function
      | (total, k) when (k = 0) -> total
      | (k, total) -> addCPS (total + k, k - 1)
         ^  ^^^
  in
       addCPS (0, n)
;;

I was just proposing :
- to use the « match with » syntax for value matching only
- to allow the use of bounded variables in the value matching
- to leave the structure match as it is of course





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