> 
> Well, I understand better and (as you may have guessed yourself!) I do
> not incline to adopt the idea.
> 
> However provided you have some 'break' construct to transfert control to
> next matching, you can perhaps compile your construct by syntactic 
> transformation.
> 
> 
> My idea is to transform your patterns into
> normal ones, replacing p <= e1 e2 ... en by fresh variables (say v)
> and then to match 'v e1 ... en' against p.
> 
> Here you have :
> 
> match e with
> | (v1, g) -> (match v1 0 with 0 -> g |_ -> break)
> | (f, v2) -> (match v2 0 with 0 -> f |_ -> break)
> | f, g -> fun x -> f x + g x
> 
> At a little additional cost in complexity,
> you can replace 'break' (which does not exists) by exceptions as follows
> 
> let x = e in
> try (match x with
>   | (v1, g) -> (match v1 0 with 0 -> g |_ -> raise Exit)
>   | _ -> raise Exit)
> with Exit ->
> try (match x with
>   | (f, v2) -> (match v2 0 with 0 -> f |_ -> raise Exit)
>   | _ -> raise Exit)
> with Exit ->
> (match x with  f, g -> fun x -> f x + g x)
> 
> 
> I am not familiar enough with Camlp4, but I have the feeling
> that some purely syntactic compilation of your construct is doable.
> Since, only from the presence of <=,
> can you introduce the extra matchings and try .. with Exit) 
> I am not saying it is easy, just that it looks feasible.
> 
> Typing and warnings are yet another issue!
> 

I agree that your translation works (I should try). I  am just wondering
about the cost (compared to a reasonable implementation inside the
compiler) ?

That would probably be not so dramatic ... except I should not transform
pattern matching that do not use the new extension ... the camlp4 code
will probably tripple what I have.

Moreover, I think I may use camlp4 for bindlib-3.0, because this really
is an extension of the language and not a library ... however I do not
think camlp4 extensions are a good thing in general, because it breaks
readability of code.

So for my extension of pattern matching with function application, I
think, I prefer to wait an adoption of a similar feature rather than
doing it myself. bindlib-3.0 will be ok without this extention of the
pattern matching.

One of the reason for my post, is that I think pattern matching should
be complete (one of the reason, is because then you can interpret the
semantics of the language by the interaction of a constructor and a
destructor ... this has something to do with a lot of reasearch work in
computational interpretation of classical logic ... and trying to move
the language in this direction looks fun ..., for instance have a look
at Herbelin's work)

> 
> -- Luc