Version française
Home     About     Download     Resources     Contact us    
Browse thread
MicMatch
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Martin Jambon <martin.jambon@e...>
Subject: Re: [Caml-list] MicMatch
On Sat, 1 Dec 2007, Jon Harrop wrote:

>
> I just stumbled upon this Wiki page discussing MicMatch:
>
>  http://ocaml.pbwiki.com/Micmatch
>
> and noted that the implementation of views disables exhaustiveness checking. I
> think it is worth keeping the static checking of view patterns.
>
> So MicMatch uses definitions like:
>
>  type 'a lazy_list = Empty | Cons of 'a * 'a lazy_list lazy_t
>
>  let view Empty = fun l -> Lazy.force l = Empty
>  let view Cons = fun l -> match Lazy.force l with Cons x -> Some x

The 2 lines above can be written in standard OCaml as follows:

let view_Empty = fun l -> Lazy.force l = Empty
let view_Cons = fun l -> match Lazy.force l with Cons x -> Some x

Now you can see better that the view "constructors" are simply independent 
functions. No magic here.

>  match ll with
>      %Empty -> ...
>    | %Cons (x, %Empty) -> ...
>    | %Cons (x1, %Cons (x2, %Empty)) -> ...
>    | _ -> ...
> 
> where F# would use:
>
>  let (|PEmpty|PCons|) l =
>    match Lazy.force l with
>    | Empty -> PEmpty
>    | Cons(h, t) -> PCons(h, t)
>
> This basically defines a new sum type and every time a view pattern is
> encountered, it is converted using this function into the new sum type and
> then matched over. This means you cannot mix view and non-view patterns in
> the same match but you do get to keep exhaustiveness checking.

Right.

In micmatch, you can do this:

match (x : int) with
   %Odd -> ...
| %Positive -> ...
| %Large -> ...
| %Even -> ...
| _ -> ...

The same int can be Odd, Positive and Large at the same time.


> Having said all of that, the only application of F#-style views in OCaml that
> I can think of is simply matching lazy values, which could be implemented
> more easily and with no syntactic overhead.
>
> There are other applications that MicMatch might not cater for. Specifically,
> factoring patterns and parameterizing patterns over values. For example, you
> might want an active pattern than handles commutativity:
>
>  Commute(p1, p2)  =>  p1, p2 | p2, p1

That could be done with camlp4, but right now there are other priorities, 
like translating micmatch to camlp4 3.10.


What was your question by the way?


Note that there's a mailing-list for micmatch if you're interested:
   http://groups.google.com/group/micmatch


--
http://wink.com/profile/mjambon
http://martin.jambon.free.fr