Re: [Caml-list] If ou Pattern-matching ?

[Nicolas Barnier <barnier@recherche.enac.fr>]

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