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

Mixin modules in a call-by-value setting, with Tom Hirschowitz.
Proceedings of ESOP 2002, LNCS 2305.
http://pauillac.inria.fr/~xleroy/publi/mixins-cbv-esop2002.pdf

The results in the paper look really exciting to my untrained eye, and I 
had a few questions...

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).

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 minix sum 
was computed.  Is this true?  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?

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?

Thanks,
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