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 BAA01074; Wed, 14 Nov 2001 01:04:07 +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 BAA01133 for ; Wed, 14 Nov 2001 01:04:06 +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 fAE042505214; Wed, 14 Nov 2001 01:04:02 +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 fAE042103551; Wed, 14 Nov 2001 01:04:02 +0100 (MET) Received: from Utilisateur ( Unverified [212.232.44.45] ) by infonie.fr with SMTP id 27291.4158235.1867325; Wed, 14 Nov 2001 01:04:01 +0100 Message-ID: <000501c16c9f$9bfe03c0$2d2ce8d4@Utilisateur> From: "Diego Olivier Fernandez Pons" To: Cc: "Caml" References: <200111121029.LAA0000005433@beaune.inria.fr><00b101c16b58$eacbbf80$9571f2c3@Utilisateur> <15344.54024.333924.7353@lachesis.inria.fr> Subject: [Caml-list] If ou Pattern-matching ? Date: Wed, 14 Nov 2001 00:57:29 +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 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