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 VAA31106; Wed, 28 Aug 2002 21:26:15 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id VAA30194 for ; Wed, 28 Aug 2002 21:26:14 +0200 (MET DST) Received: from relay.pair.com (relay1.pair.com [209.68.1.20]) by nez-perce.inria.fr (8.11.1/8.11.1) with SMTP id g7SJQDD17597 for ; Wed, 28 Aug 2002 21:26:13 +0200 (MET DST) Received: (qmail 49408 invoked from network); 28 Aug 2002 19:26:11 -0000 Received: from slip139-92-234-94.por.uk.prserv.net (HELO checkerlap.d6.com) (139.92.234.94) by relay1.pair.com with SMTP; 28 Aug 2002 19:26:11 -0000 X-pair-Authenticated: 139.92.234.94 Message-Id: <4.3.2.7.2.20020828121746.02985ce0@mail.d6.com> X-Sender: checker@mail.d6.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 28 Aug 2002 12:25:16 -0700 To: tom.hirschowitz@inria.fr From: Chris Hecker Subject: Re: [Caml-list] mixin modules paper and future? Cc: caml-list@inria.fr In-Reply-To: <15724.36133.967472.326610@paille.inria.fr> References: <4.3.2.7.2.20020826201812.02c89e20@mail.d6.com> <4.3.2.7.2.20020826201812.02c89e20@mail.d6.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk >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