From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id FAA14678; Tue, 27 Aug 2002 05:35:27 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id FAA14717 for ; Tue, 27 Aug 2002 05:35:26 +0200 (MET DST) Received: from relay.pair.com (relay1.pair.com [209.68.1.20]) by concorde.inria.fr (8.11.1/8.11.1) with SMTP id g7R3ZPf15973 for ; Tue, 27 Aug 2002 05:35:25 +0200 (MET DST) Received: (qmail 43266 invoked from network); 27 Aug 2002 03:35:19 -0000 Received: from slip32-106-38-149.por.uk.prserv.net (HELO checkerlap.d6.com) (32.106.38.149) by relay1.pair.com with SMTP; 27 Aug 2002 03:35:19 -0000 X-pair-Authenticated: 32.106.38.149 Message-Id: <4.3.2.7.2.20020826201812.02c89e20@mail.d6.com> X-Sender: checker@mail.d6.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 26 Aug 2002 20:33:47 -0700 To: caml-list@inria.fr From: Chris Hecker Subject: [Caml-list] mixin modules paper and future? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk 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