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 BAA01451; Wed, 14 Nov 2001 01:04:03 +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 BAA01289 for <caml-list@pauillac.inria.fr>; Wed, 14 Nov 2001 01:04:02 +0100 (MET)
Received: from transmail12.infosources.fr (transmail12.infosources.fr [212.232.33.78])
	by concorde.inria.fr (8.11.1/8.10.0) with ESMTP id fAE040j00462;
	Wed, 14 Nov 2001 01:04:00 +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 fAE040103543;
	Wed, 14 Nov 2001 01:04:00 +0100 (MET)
Received: from Utilisateur ( Unverified [212.232.44.45] ) by infonie.fr with SMTP id 27291.4158235.1867316;
	Wed, 14 Nov 2001  01:03:59  +0100
Message-ID: <000401c16c9f$9b23d060$2d2ce8d4@Utilisateur>
From: "Diego Olivier Fernandez Pons" <FernandezPons@iFrance.com>
To: "Luc Maranget" <luc.maranget@inria.fr>
Cc: "Caml" <caml-list@inria.fr>
References: <200111131609.RAA0000023991@beaune.inria.fr>
Subject: [Caml-list] Deux types de pattern-matching ?
Date: Wed, 14 Nov 2001 00:56:05 +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

< C'est très intéressant, car le pattern matching n'a qu'une seule
< définition.

Je ne suis pas informaticien de formation, encore moins spécialiste de
la sémantique des langages. Mon approche pour cette raison est
purement pragmatique :

let valeur = function
  | (1,2) -> 0
  | (1, snd) -> snd
  | (fst, snd) -> fst

Filtrage par valeurs : on peut transformer en « if then else »

let valeurs = function (x, y) ->
    if (x = 1) && (y = 2) then 1
    else if (x = 1) then y
    else x
;;

De même le code suivant

let valeur = function
  | [ ] -> 0
  | [1; 3] -> 1
  | _ -> 2

Par contre

let structure = function
  | [ ] -> 0
  | [x; 1] -> x
  | _ -> 2
;;

on ne peut pas transformer en « if then else » seul, il faut
utiliser un let destructurant (pour faire l'unification)

let structure = function liste ->
  if (liste = [ ]) then 0
  else
      let (x :: reste) = liste in
      if (reste = [1]) then x else 2
;;

Pour moi un code comme :

match couple with
| (0, 1) -> 0
| (1, y) -> y
| (x, y) -> x

commence par destructurer couple puis fait un filtrage de valeurs

let (x,y) = couple in
  match (x,y) with
  | (0,1) -> 0
  | (1, _) -> y
  | (_, _) -> x

Une seule liaison des variables x et y puis comparaisons (les
unifications multiples ne se justifient pas)
C'est d'ailleurs ce que fait la définition d'une fonction

let valeurs = function (x,y) -> [...]
let valeurs = function couple -> let (x,y) = couple in [...]

Autrement dit, je décompose le filtrage de motif en deux opérations
élémentaires :
  i) l'unification
  ii) disjonction de cas

Ce qui donne 3 « types » de filtrages
  - disjonction de cas (éventuellement précédée d'une unification)
  - unification (éventuellement suivie d'une disjonction)
  - mélange des deux

Je proscris pour les raisons déjà expliquées le mélange (risques
d'erreur liées aux variables muettes...) et recommande au lieu
l'enchaînement des deux opérations élémentaires

Bien sûr, formellement le code suivant
  match liste with
  | [x; 1] -> x
est équivalent à une disjonction de cas infinie
  ...
  | [0; 1] -> 0
  | [1; 1] -> 1
  | [2; 1] -> 2
  ...
Ce qui en ferait un filtrage de structure serait l'utilisation dans le
second membre d'un motif interne au premier membre, cela dit

let valeur = function
 | [ ] -> 0
 | [ _ ; 1] -> 1
 | _ ->2

ne peut pas se transformer en « if then else » sans unification et
n'utilise pas de motif interne au premier membre ce qui finit
d'achever la séparation des deux notions  : d'un point de vue
théorique elle est parfaitement vaseuse.

De toutes les façons, vous ne pouvez pas demander aux utilisateurs
d'un langage de comprendre parfaitement les fondements théoriques de
celui-ci pour l'utiliser correctement, sous peine de produire un
langage qui - comme Caml actuellement - ne dépassera jamais le cadre
des universitaires. Il faut résoudre un certain nombre de problèmes
pragmatiques liés à l'usage, et les erreurs (nombreuses) liées au
pattern matching en sont un.

        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