Re: [Caml-list] Patterns that evaluate

[Jacques Garrigue <garrigue@math.nagoya-u.ac.jp>]

From: Martin Jambon <martin.jambon@ens-lyon.org>
> 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