>You're right, it is not at all planned for any future release. There
>are too many open questions yet even to make any guess whether it will ever
>find its way.  But thanks for your interest!

Hopefully you guys are actively working on solving the open 
problems.  :)  I think that this is an incredibly important feature for 
caml to make headway into large systems development.

>But maybe you are asking for optimizations performing such tasks at
>compile-time?

Yeah, at least for the easy cases.  My thought is that people will start 
using it to decouple large modules into different files, and it would be 
nice if that simple case (basically, mirroring using a header to split a 
big interdependent system across multiple C files) incurred no runtime 
overhead.  However, it's much more important to solve the open research 
problems than it is to optimize it, so ignore this for now.  :)

 > Yes, we meant the type declaration of the deferred values. If a
>deferred mixin is expected, its type must be provided by the
>programmer.

Ah, okay.  I guess it doesn't seem unreasonable to me to force the 
programmer to specify types for the deferred values, but maybe I haven't 
gotten used to type inference enough to be annoyed by this yet.  One thing 
is for certain:  it would be MUCH better to implement this feature 
requiring type declarations than to sit on it until you figure out how to 
do inference on deferred values.  Caml programmers are used to specifying 
types in mli files anyway, so it's just not a big deal.  Unless I'm missing 
something important.

Keep up the good work!
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