[Caml-list] mixin modules paper and future?

[Tom Hirschowitz <tom.hirschowitz@inria.fr>]

Hi Chris, 

 > While looking around Xavier's site, I came across this new paper (at least, 
 > new since last time I looked):
Last January yes.

 > 1.  First, the annoying obvious question:  Any wild guesses when this work 
 > will find its way into caml?  
 > I read the whole paper, but had to skim the 
 > lambda calc sections since my lambda-fu is not strong.  It's clear there 
 > are a number of open problems, so it's obviously not imminent in the next 
 > release, but it sure is cool (the way it unifies functors and recursion is 
 > great).

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!

 > 2.  The paper has a few places where it mentions work that has to be done 
 > at init time, which sounded like runtime at the point where the mixin sum 
 > was computed.  Is this true?  

Almost, it would rather be at the time when the mixin is instanciated
(ie "closed").

 > For the very simple case of "I want to 
 > recurse between two compilation units like C++", is there still overhead 
 > that must happen at runtime and that can't be done at compile time?

In the present system yes, and it is a matter of design I believe.
For instance, even for your simple case, you have to first write unit
A, then unit B, and then create C = close(A + B), and that's in the
source language, so closing the recursion loop is really an operation
of the language.

But maybe you are asking for optimizations performing such tasks at
compile-time?  We haven't thought too much about such optimizations
yet, and that's probably a good question.  It is not a priority
though, since some design problems remain open, and the efficiency of
taking a mixin module instance is not supposed to be critical, in the
context of an extension of ML modules.

Please, tell me if I missed your point.

 > 3.  The following is from the paper:
 > 
 > >A drawback of dependency graphs is that programmers must (in principle)
 > >provide them explicitly when declaring a mixin signature, e.g. for a deferred
 > >sub-mixin component. This could make programs quite verbose.
 > 
 > I may have missed it, but I didn't see where this explicit graph thing came 
 > in, since none of the examples had it.  I assume you don't mean the type 
 > declaration of the deferred values, right?  Is there some other 
 > specification that's necessary?

Yes, we meant the type declaration of the deferred values. If a
deferred mixin is expected, its type must be provided by the
programmer. In the paper, we don't have considered type inference
issues, but it seems to be far from trivial, as described by papers
about objects and classes, which appear to have similar problems.

Bye,

Tom
-------------------
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