Re: [Caml-list] Again on pattern matching and strings

[Christopher Quinn <cq@htec.demon.co.uk>]

Alessandro Baretta wrote:
> 
> I write this message because I would like to know what kind of 
> complications would need to be added to the compiler to make the above 
> trick work.
> 
> Alex

there is John Reppy's Abstract Value Constructors (no weblink found but i have the paper).

example syntax:
const K = <some pattern>
const K(a,b) = <pattern with holes a&b>

i have a patch but its against 3.01.
the main problem is that making a constant abstract via a signature means referencing it incurs an unavoidable function call (under the bonnet), which is mightily inefficient compared to the usual compiled match. in effect the client code gets the module containing the definition to do the pattern matching for it. 
of course, to retain efficiency simply don't bother with an mli on modules containing const definitions! (or internal signatures) 
since separate compilation is then lost this would be an argument against such a practice. but it is no worse a situation than variant constructors in a signature file because in that case no change can be made to the definition in the implementation file that does not require having to do the same in the interface file. hence re-compilation of all dependent code.
a practical approach to minimise the effect of this is to put one's constant definitions into their own .ml file (ie. no other values that might have dependents in addition to those of the constants)

but a final solution to this might be a similar one to work on functor elimination(?) - develop conscientiously with abstracted modules, but then do a final recompilation that ignores abstraction and inlines constants, for efficiency sake.

in any case the patch includes a compiler switch to 
turn off signature coercion, by which i mean any present signature is properly matched against the implementation as normal but is discarded afterwards in favour of whatever the compiler inferred for the implementation itself. result: inlined constants in the presence of signature abstraction.
this is largely untested, is definitely incomplete with respect to functors, and likely to cause the typechecker to complain in certain situations (not constraining a type as intended by sig.)

also i think i neglected to sort out the case of ocamlopt when a signature defines a different order for values than they actually occur in the implementation (a coercion issue).

there is another minor limitation with respect to functors but otherwise named patterns work as expected.

- chris

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners