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 KAA10580; Wed, 28 Aug 2002 10:43:51 +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 KAA10765 for ; Wed, 28 Aug 2002 10:43:51 +0200 (MET DST) Received: from paille.inria.fr (paille.inria.fr [128.93.11.15]) by concorde.inria.fr (8.11.1/8.11.1) with ESMTP id g7S8hIv00761; Wed, 28 Aug 2002 10:43:18 +0200 (MET DST) Received: (from hirschow@localhost) by paille.inria.fr (8.11.6/8.11.6) id g7S8hId01923; Wed, 28 Aug 2002 08:43:18 GMT From: Tom Hirschowitz MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15724.36133.967472.326610@paille.inria.fr> Date: Wed, 28 Aug 2002 08:43:17 +0000 To: Chris Hecker Cc: caml-list@inria.fr Subject: [Caml-list] mixin modules paper and future? In-Reply-To: <4.3.2.7.2.20020826201812.02c89e20@mail.d6.com> References: <4.3.2.7.2.20020826201812.02c89e20@mail.d6.com> X-Mailer: VM 6.97 under Emacs 21.2.1 Reply-To: tom.hirschowitz@inria.fr Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk 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