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 LAA06689; Wed, 14 Nov 2001 11:47:23 +0100 (MET) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id LAA07037 for ; Wed, 14 Nov 2001 11:47:22 +0100 (MET) Received: from indigo.recherche.enac.fr (indigo.recherche.enac.fr [195.220.158.66]) by concorde.inria.fr (8.11.1/8.10.0) with ESMTP id fAEAlL515496 for ; Wed, 14 Nov 2001 11:47:21 +0100 (MET) Received: from mauve.recherche.enac.fr (mail@mauve.recherche.enac.fr [10.31.3.2]) by indigo.recherche.enac.fr (8.8.6 (PHNE_14041)/8.6.11) with ESMTP id LAA09154; Wed, 14 Nov 2001 11:47:18 +0100 (MET) Received: from beige.recherche.enac.fr ([10.31.1.89] ident=barnier) by mauve.recherche.enac.fr with smtp (Exim 3.31 #1 (Debian)) id 163xZd-0006ry-00; Wed, 14 Nov 2001 11:47:17 +0100 Received: by beige.recherche.enac.fr (sSMTP sendmail emulation); Wed, 14 Nov 2001 11:47:22 +0100 Content-Type: text/plain; charset="iso-8859-1" From: Nicolas Barnier Reply-To: barnier@recherche.enac.fr To: "Diego Olivier Fernandez Pons" Subject: Re: [Caml-list] If ou Pattern-matching ? Date: Wed, 14 Nov 2001 11:47:22 +0100 X-Mailer: KMail [version 1.2] Cc: "Caml" References: <200111121029.LAA0000005433@beaune.inria.fr> <15344.54024.333924.7353@lachesis.inria.fr> <000501c16c9f$9bfe03c0$2d2ce8d4@Utilisateur> In-Reply-To: <000501c16c9f$9bfe03c0$2d2ce8d4@Utilisateur> MIME-Version: 1.0 Message-Id: <01111411472206.27595@beige> Content-Transfer-Encoding: 8bit Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk On Wednesday 14 November 2001 00:57, Diego Olivier Fernandez Pons wrote: > > 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 » Si si, ces deux conseils doivent s'appliquer en réfléchissant. > let somme = function n -> > if n = 0 then 0 > else (k + somme (k-1)) Pourquoi des "function" quand la fonction n'est pas définie par extension ? > Le code avec filtrage que je présente assure : > - une indentation uniforme (ce qui ne serait pas le cas avec des if) Mais si, on peut indenter de manière uniforme et structurée (si on regroupe des cas, chose que l'on fait également avec des pattern matching imbriqués) avec des if : if then else if then else if then else Tout est indenté au même niveau. > 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 Il n'y a pas de différences sémantique, c'est de la syntaxe. D'ailleurs le code suivant est très proche du précédent (mais il faut un rec et en général on évite de mettre des parenthèses autour des arguments sinon les étudiants ont du mal à comprendre le concept d'application) : let rec longueur l = if l = [] then 0 else let _ :: reste = l in 1 + longueur reste Sauf que c'est insupportable parce que ça génère un warning. De toute façon, dès qu'on doit effectuer un traitement uniforme sur une structure de données de type somme, on recopie la définition du type et on remplace les "of" par des flèches. Les listes ne font pas exception. Pour un type produit au contraire, le choix entre les deux constructions est moins immédiat - et parfois uniquement une affaire de goût, mais, vous me rétorqueriez sans doute "Chacun son mauvais goût". > 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) Ce souci de compatibilité vous honore. > et permettrait la comparaison avec des valeurs précédemment liées. > > Critiques : > - tout le monde est heureux dans la vie sauf toi (Le Fessant) > - apprends la sémantique des constructions Caml avant de les > utiliser (Le Fessant) Je dois dire que je soutiens les commentaires de Fabrice Le Fessant. > - le langage devrait aider le programmeur à coder facilement des > programmes robustes et lisibles A quel langage pensez-vous ? Personnellement, je n'en ai jamais rencontré qui permette autant que Caml d'éviter les constructions foireuses : les règles sont simples et claires, et on peut se contenter d'un sous-ensemble très cohérent du langage pour l'enseignement (e.g. obliger à mettre les "fun" ou interdire les "then" sans "else" même quand on n'effectue qu'un effet de bord). > peux dire plutôt que je propose l'introduction d'un « multi-switch » > qui serait bien utile. Ben nan parce qu'on a déjà le pattern matching. > 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. Mais vous refusez d'entendre raison malgré les efforts multiples de l'équipe de développement qui a sûrement des choses importantes à faire ! Et vous faites des commentaires erronés et désobligeants : > [...] sous peine de produire un langage qui - comme Caml actuellement - ne > dépassera jamais le cadre des universitaires. On soupçonne donc un tempérament peu enclin à se laisser convaincre même par les arguments les plus rationnels et plutôt disposer à en découdre à tout prix - uniquement sur le sujet du pattern matching bien entendu. Bref votre opinion est ferme et définitive et vous n'écrivez pas pour qu'on éclaire votre lanterne. > 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. Sans commentaire. Cordialement. -- Nicolas ------------------- 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