From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.4 required=5.0 tests=AWL,DNS_FROM_RFC_ABUSE autolearn=disabled version=3.1.3 Received: from discorde.inria.fr (discorde.inria.fr [192.93.2.38]) by yquem.inria.fr (Postfix) with ESMTP id 55B82BC0A for ; Thu, 15 Feb 2007 01:26:46 +0100 (CET) Received: from kurims.kurims.kyoto-u.ac.jp (kurims.kurims.kyoto-u.ac.jp [130.54.16.1]) by discorde.inria.fr (8.13.6/8.13.6) with ESMTP id l1F0Qi9S002175 for ; Thu, 15 Feb 2007 01:26:45 +0100 Received: from localhost (orion [130.54.16.5]) by kurims.kurims.kyoto-u.ac.jp (8.13.7/8.13.7) with ESMTP id l1F0QcAl014499; Thu, 15 Feb 2007 09:26:38 +0900 (JST) Date: Thu, 15 Feb 2007 09:26:32 +0900 (JST) Message-Id: <20070215.092632.112616570.garrigue@math.nagoya-u.ac.jp> To: martin.jambon@ens-lyon.org Cc: caml-list@yquem.inria.fr Subject: Re: [Caml-list] Patterns that evaluate From: Jacques Garrigue In-Reply-To: References: <45D23608.4030104@mcmaster.ca> <200702132207.33793.jon@ffconsultancy.com> X-Mailer: Mew version 4.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Miltered: at discorde with ID 45D3A8C4.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; ens-lyon:01 ocaml:01 ocaml's:01 bug:01 afaik:01 ocaml's:01 syntax:01 msdn:01 dsyme:01 vice-versa:01 reusing:01 reusing:01 compilation:01 2007,:98 equality:01 From: Martin Jambon > On Tue, 13 Feb 2007, Jon Harrop wrote: > > On Tuesday 13 February 2007 22:04, Jacques Carette wrote: > > > I recently wrote some ocaml code which "worked", but not as I > > > intended... The test cases I tried worked, but I should have tested > > > harder. Apparently I was under the mistaken impression that OCaml's > > > pattern-matching was more "first class"! So I wrote (in part): > > > > > > let buildsimp cast e f1 f2 = fun e1 -> fun e2 -> match (e1,e2) with > > > > > > | ({st = Some e}, _) -> e2 > > > > > > and I expected it to work. Only a code review by a colleague 'found' > > > this bug in my code. > > > > > > Question: would it be a difficult extension? This seemed so "natural", > > > I just "used" the feature before it was quite there yet ;-). > > > > F# just introduced active patterns, which does what you want AFAIK. Of course, > > you must disambiguate that from the OCaml's current interpretation of the > > above (binding "e"). > > That's funny, I posted a syntax extension that does that one week ago, > but I didn't know it was already implemented in F#. > http://caml.inria.fr/pub/ml-archives/caml-list/2007/02/e397c716c448a0aeff92b7af709bb1b4.en.html > http://blogs.msdn.com/dsyme/archive/2006/08/16/ActivePatterns.aspx > > "Active patterns" seems to be another name for "simple views" or > vice-versa. > > It converged to an extremely similar solution, so it must be a good one > :-) > > It doesn't solve the original problem though, which IMHO is better solved > with a standard "when" guard as mentioned earlier. Martin, I think you have a lot of good points here. "when" clauses were exactly introduced in order to solve this kind of problems. However, I agree with the other Jacques that reusing an existing variable in a pattern-matching is a common error, so it might be a good idea to have a warning for that. Unused variable warnings were introduced relatively recently, and there is still work to do on misuse of variables. Note that reusing variable names is a common idiom, so we don't want to disallow it completely, but "masking a local variable in a pattern matching with several branches", as done above, looks like something very suspicious. The other question is on views. They could maybe help in this case, using a parameterized view that checks equality with it parameter, but this seems far-fetched. However, they have plenty of other applications where they would be very useful. As with any extension, an important question with views is whether they should be in the language, as in F#, or supported by the preprocessor as you did. After all, pattern-matching in Scheme is entirely based on macros, and people are perfectly happy with that. Why is it not the case in ML? Because, thanks to typing, we can check exhaustivity and overlapping, and use this information to detect error and optimize compilation. Unfortunately, views do not allow that, so there seems to be less incentive to make them a core feature. There was a lot written about the need for views to be proved bijective before they can be mixed freely with pattern-matching, but such proof doesn't seem practical for now. This may explain why, while they look like a natural extension of pattern-matching, they are not a standard feature. Jacques Garrigue