From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id WAA12958; Mon, 12 Nov 2001 22:05:26 +0100 (MET) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id WAA13021 for ; Mon, 12 Nov 2001 22:05:24 +0100 (MET) Received: from transmail12.infosources.fr (transmail12.infosources.fr [212.232.33.78]) by nez-perce.inria.fr (8.11.1/8.10.0) with ESMTP id fACL5NH08615; Mon, 12 Nov 2001 22:05:23 +0100 (MET) Received: from infonie.fr (mailbox.infonie.fr [195.242.64.77]) by transmail12.infosources.fr (8.11.6/8.11.6) with SMTP id fACL5N101080; Mon, 12 Nov 2001 22:05:23 +0100 (MET) Received: from Utilisateur ( Unverified [195.242.113.149] ) by infonie.fr with SMTP id 27291.3175560.1418513; Mon, 12 Nov 2001 22:05:22 +0100 Message-ID: <00b101c16b58$eacbbf80$9571f2c3@Utilisateur> From: "Diego Olivier Fernandez Pons" To: "Luc Maranget" Cc: "Caml" References: <200111121029.LAA0000005433@beaune.inria.fr> Subject: Re: [Caml-list] Pattern matching Date: Mon, 12 Nov 2001 10:00:32 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk 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