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 OAA21782 for caml-redistribution; Fri, 15 Nov 1996 14:18:40 +0100 (MET) Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id VAA08728 for ; Thu, 14 Nov 1996 21:50:54 +0100 (MET) Received: from charon.alto.org (charon.alto.org [194.167.80.13]) by nez-perce.inria.fr (8.7.6/8.7.1) with SMTP id VAA13022; Thu, 14 Nov 1996 21:50:51 +0100 (MET) Received: from gw-msmail.ac-dijon.fr (gw-msmail.ac-dijon.fr [194.167.18.12]) by charon.alto.org (8.6.12/8.6.12) with SMTP id VAA24541; Thu, 14 Nov 1996 21:49:42 +0100 Received: by gw-msmail.ac-dijon.fr with Microsoft Mail id <328C0486@gw-msmail.ac-dijon.fr>; Thu, 14 Nov 96 21:49:58 PST From: "QUERCIA Michel (T) Math" To: "'Pierre Weis'" Cc: "'caml-list'" Subject: RE: match values Date: Thu, 14 Nov 96 22:59:00 PST Message-ID: <328C0486@gw-msmail.ac-dijon.fr> Encoding: 112 TEXT X-Mailer: Microsoft Mail V3.0 Sender: weis En francais >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 ?) Exact, en fait je pensais a un match sur une expression calculee, le match faisant partie d'un code plus gros, et pas specifiquement a un parametre d'une fonction. >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) ? L'egalite recursive me parait plus pertinente que l'egalite physique, il y a un risque de bouclage mais il n'est pas plus important que celui du code que je propose de remplacer. Par ailleurs, a propos de l'impossibilite de tester l'egalite structurelle des fonctions, ni de toute structure comportant une valeur fonctionnelle quelle est la raison de cette impossibilite ? Je peux comprendre qu'on ne puisse verifier si deux codes differents produisent le meme resultat, mais pourquoi ne pas declarer differentes deux fonctions ayant des adresses memoire differentes ? Le resultat n'est pas une egalite au sens fonctionnel, mais permet quand meme de comparer des structures comportant des fonctions (je pense par exemple a l'arbre d'une expression arithmetique dont les noeuds seraient etiquetes par les fonctions d'evaluation). >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: >... >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). Tout a fait d'accord. Je me souviens avoir soumis cette proposition du "when" l'annee derniere, votre conclusion etant "y a qu'a le faire !". ================================================================ [In english] >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 ? True, actually I was thinking about a "match" included in some bigger code, and "x" could be some calculated expression. [Here should come some consideration about functionnal comparison, but that's too hard english for me ...] >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. I think structural equality would be preferable. It could not terminate, but this is another problem which is allready present in the two codes I want to replace. >It seems that once more you are looking for the when construct, a >generalised if then else, already proposed here: >... >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. I fully agree with this. Maybe for Caml-Light 0.72 or Ocaml 1.04 ? >Pierre Weis Michel Quercia Lycee Carnot querciam@l-carnot1.ac-dijon.fr