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 LAA06485; Wed, 14 Nov 2001 11:19:42 +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 LAA06298 for ; Wed, 14 Nov 2001 11:19:41 +0100 (MET) Received: from beaune.inria.fr (beaune.inria.fr [128.93.8.3]) by concorde.inria.fr (8.11.1/8.10.0) with ESMTP id fAEAJe514247; Wed, 14 Nov 2001 11:19:40 +0100 (MET) Received: by beaune.inria.fr (8.8.8/1.1.22.3/14Sep99-0328PM) id LAA0000031670; Wed, 14 Nov 2001 11:19:40 +0100 (MET) From: Luc Maranget Message-Id: <200111141019.LAA0000031670@beaune.inria.fr> Subject: [Caml-list] Re: Deux types de pattern-matching ? To: FernandezPons@iFrance.com (Diego Olivier Fernandez Pons) Date: Wed, 14 Nov 2001 11:19:40 +0100 (MET) Cc: luc.maranget@inria.fr (Luc Maranget), caml-list@inria.fr (Caml) In-Reply-To: <000401c16c9f$9b23d060$2d2ce8d4@Utilisateur> from "Diego Olivier Fernandez Pons" at nov 14, 2001 12:56:05 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit 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 : Bon j'en ai rajouté. Mais mon point reste de proposer une vue simple et uniforme du filtrage. Nul besoin d'être spécialiste de la sémantique, je vais essayer un point de vue de compilation de Caml dans lui même. > > 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) > Ben c'est pas comme ça que je présenterais les choses > let structure = function liste -> > if (liste = [ ]) then 0 > else > let (x :: reste) = liste in > if (reste = [1]) then x else 2 > ;; Ça ne résoud pas le pb du pt de vue de la compilation, car il reste un filtrage. Supposons en plis du if, données deux fonctions ``car'' et ``cdr'' (qui sont en fait de facons plus génerales des fonction d'accès aux champs d'une cellule de liste, ie des accès indexés) car x est (getfield 0 x) Alors la compilation de structure est let structure = function liste -> if (liste = [ ]) then 0 else let x = car x and reste = cdr list in if (reste = []) then 2 else let tmp1 = car reste and tmp2 = cdr reste in if tmp1 = 1 then if tmp2 = [] then x else 2 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 Non c'est, filtrage (et non pas unification, c'est pas pareil) avec liasons éventuelle de variables des variables des filtres aux champs correspondants des valeurs filtrées. J'ai l'air d'un vieux chouf, mais je crois que c'est comme ça qu'on comprend le mieux. > > 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 > ... Non. La définition complète du filtrage (reporter vous au prédicat ``<='' du message précédent) n'a pas besoin de ce truc pour définir le filtrage par un motif contenant une variable. (Même si en un sens l'équivalence est valide, mais elle n'aide pas à comprendre ce qui se passe. au niveaux élémentaire un filtre ``_::_'' est équivalent au prédicat ``c'est un cons'' (consp en lisp). > 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. > C'est bien le problème. Pour avoir un langage de programmation pas trop bizarre, un peu de théorie ne nuit jamais. La « théorie » n'est pas le mal, n'est pas hors de portée. Je ne crois pas que l'on puisse réellement programmer en utlisant le filtrage, sans tout à fait comprendre ce qui se passe. prenons un exemple extrêment simple qui évite les motifs trop compliqués (c'est aussi un pb) let f liste = match l with | [] -> 0 | x::_ -> x c'est let f liste = if liste = [] then 0 else > 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