From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: weis Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id QAA01336 for caml-redistribution; Thu, 14 Nov 1996 16:05:03 +0100 (MET) 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 QAA01255 for ; Thu, 14 Nov 1996 16:03:27 +0100 (MET) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by concorde.inria.fr (8.7.6/8.7.1) with ESMTP id QAA01410; Thu, 14 Nov 1996 16:03:26 +0100 (MET) Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id QAA01251; Thu, 14 Nov 1996 16:03:25 +0100 (MET) From: Pierre Weis Message-Id: <199611141503.QAA01251@pauillac.inria.fr> Subject: Re: match values In-Reply-To: <328A4CA0.D18858A@l-carnot1.ac-dijon.fr> from Quercia at "Nov 13, 96 10:33:04 pm" To: querciam@l-carnot1.ac-dijon.fr Date: Thu, 14 Nov 1996 16:03:24 +0100 (MET) Cc: caml-list@inria.fr MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: weis [En francais] > Le code Caml suivant ne fonctionne pas comme on pourrait le vouloir : > > let f(x,y,z) = match x with > | y -> ... > | z -> ... > | _ -> ... > ;; [...] > 1. de modifier la syntaxe de "match" de sorte que les identificateurs > soient evalues s'ils ne sont pas precedes de "as" comme dans : > > match x with > | y -> ... (* comparaison des valeurs x et y *) > | _ as t -> ... (* definition de l'identificateur t *) Je ne comprends pas bien la ligne ``_ as t -> ...'' que vaut t ? que signifie le souligne' ? La seule re'ponse plausible me semble e^tre ``t vaut x'' et ``_'' ne sert a` rien. (mais si t est un alias pour x alors pourquoi de'finir t ?) > 2. d'introduire une nouvelle forme de filtrage "matchval" qui evaluerait > les motifs avant de proceder a la comparaison, en conservant la > possibilite > de definir un nouvel identificateur par "_ as " ? Le proble`me est justement dans le terme comparaison: le filtrage posse`de une se'mantique bien pre'cise lie'e a` la comparaison structurelle des donne'es, alors que votre proposition introduit un appel implicite a` des fonctions de comparaison plus se'mantiques. Se pose alors imme'diatement le proble`me du choix de cette comparaison: comparaison physique (==) ou e'galite' structurelle re'cursive (=) ou isomorphisme d'arbres rationnels (equal en Caml V3.1), ou e'galite' se'mantique adapte'e au type des ``filtres''. Le proble`me de la pertinence de la comparaison se pose aussi: que faire si le motif s'e'value en une fonction ? plus ge'ne'ralement en une valeur qui n'admet pas l'e'galite' (valeur d'un type abstrait par exemple) ? Il me semble encore une fois que la construction cherche'e est la construction when, une ge'ne'ralisation du if then else de'ja` propose'e ici: Syntaxe: when | cond1 -> e1 | cond2 -> e2 ... (| condn -> en) | (| _ -> en) Se'mantique: if cond1 then begin e1 end else if cond2 then begin e2 end else ... begin en end, dans le cas | _ -> en if condn then begin en end else (), dans le cas | condn -> en Ainsi la fonction d'e'galite' est explicite et laisse'e au choix du programmeur. Votre exemple devient: let f(x,y,z) = when | x = y -> ... | x = z -> ... | _ -> ...;; L'avantage est que maintenant la condition peut e^tre plus ge'ne'rale qu'une e'galite': let f(x,y,z) = when | x < y -> ... | x + y >= z -> ... | _ -> ...;; Cette construction est simple a` imple'menter (4 lignes dans l'analyseur syntaxique suffisent) et permet d'e'crire e'le'gamment les tests complexes. Son seul inconve'nient est d'offrir une alternative supple'mentaire au if then else. Pour ma part, j'e'changerais volontier le if then else (avec ses lourdes parenthe`ses begin end en cas de se'quences) contre le when (et ses e'le'gants symboles | et ->, re'miniscents du filtrage et moins sensible aux se'quences). [In english] > The following Caml code does not work as one would expect : > > let f(x,y,z) = match x with > | y -> ... > | z -> ... > | _ -> ... [...] > 1. modify "match" syntax so that identifiers are evaluated unless they > are > precededed by "as" as in : > > match x with > | y -> ... (* comparison of the values of x and y *) > | _ as t -> ... (* definition of identifier t *) I don't understand the last line ``_ as t -> ...'': what means the underscore and what's the value of t ? My interpretation: t is a useless alias for x ? ``_'' is useless ? > 2. introduce a new form of pattern-matching "matchval" which would > evaluate the patterns before comparison, preserving the possibility > to define a new identifier with a "_ as " construct ? The problem is the ``comparison'': the actual pattern matching feature has a precise semantics, bound to the structural comparison of data. Your proposition means introducing implicit calls to more semantical comparison functions. Thus, we have to choose this implicit comparison: physical identity (==), recursive structural equality (=), rational trees isomorphism (equal in Caml V3.1), or even some semantical equality specialized to the type of ``patterns''. This problem may not be trivial, if solvable at all, for functions or abstract data types. It seems that once more you are looking for the when construct, a generalised if then else, already proposed here: Syntax: when | cond1 -> e1 | cond2 -> e2 ... (| condn -> en) | (| _ -> en) Se'mantics: if cond1 then begin e1 end else if cond2 then begin e2 end else ... begin en end, dans le cas | _ -> en if condn then begin en end else (), in the case | condn -> en Now the equality test is explicit and written by the programmer: let f(x,y,z) = when | x = y -> ... | x = z -> ... | _ -> ...;; Moreover, the conditions are not restricted to be equality tests: let f(x,y,z) = when | x < y -> ... | x + y >= z -> ... | _ -> ...;; By the way, this construct is simple to implement (4 lines in the parser) and provides a clear way to write complex tests. Its only drawback is to be a bit redundant with if. In my opinion, the when construct is a profitable alternative to if then else: its separator symbols | and -> are intuitive to the Caml programmer, since they are reminiscent to those of pattern matching. Moreover, in the presence of imperative sequences of expressions, the when construct is syntactically superior. Pierre Weis INRIA, Projet Cristal, Pierre.Weis@inria.fr, http://pauillac.inria.fr/~weis