> 
> I agree that your translation works (I should try). I  am just wondering
> about the cost (compared to a reasonable implementation inside the
> compiler) ?
> 
More expansive as camlp4 than coded inside the compiler.
But well, is cost a real problem here ?



> 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.
Not necesssarily, I guess, there is no need to transform patterns
without <=. An easy way out would be to introduce a new kind of
match expressions (extend_match ...  with .. ) which would
be the only one to accept <= in patterns.

> 
> 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.
I may not have been as clear as I wish to: I will not implement this.
As you see, it is really complicated (think about or-patterns,
or nested <=, for instance).

However, something like 'break' could perhaps be introduced in
a forseable future.



-- Luc