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 SAA07756; Mon, 17 Mar 2003 18:06:14 +0100 (MET) 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 SAA26153 for ; Mon, 17 Mar 2003 18:06:12 +0100 (MET) From: brogoff@speakeasy.net Received: from grace.speakeasy.org (grace.speakeasy.org [216.254.0.2]) by nez-perce.inria.fr (8.11.1/8.11.1) with SMTP id h2HH6BX08257 for ; Mon, 17 Mar 2003 18:06:11 +0100 (MET) Received: (qmail 2740 invoked by uid 36130); 17 Mar 2003 17:06:09 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 17 Mar 2003 17:06:09 -0000 Date: Mon, 17 Mar 2003 09:06:09 -0800 (PST) To: Chris Hecker cc: "caml-list@pauillac.inria.fr" Subject: Re: Module recursion (Was Re: [Caml-list] Re: Haskell-like syntax) In-Reply-To: <4.3.2.7.2.20030316205959.045990d8@localhost> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam: no; 0.00; brogoff:01 recursion:01 caml-list:01 haskell-like:01 hecker:01 recursively:01 functor:01 functors:01 jacques:01 incarnation:01 fergus:01 kloc:01 mli:01 refactor:01 decoupling:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk On Sun, 16 Mar 2003, Chris Hecker wrote: > >Are you sure you agree? > > I agree with what I thought you were saying. :) I thought we had the same > high-concept, which is just that you can apply the 80/20 rule here and do > _something_ to alleviate the DAG module problem without doing some totally > general thing like Tom's mixin modules thing. Yes, we have the same high level concept, namely, that we can look for solutions to specific problems that result from not being able to call modules recursively, without solving the whole thing, as with mixin modules. I think any disagreement was more one of degree, in that my "pet problem(s)" are not prioritized the same way yours are. I won't give percentages, since I don't know what they mean in this context. I find that the inability to have type declarations recursive with functor instantiation reduces the value of functors, and the workaround (the parameterization trick) forces you to introduce polymorphism just to do this. I agree that the lack of cross module function recursion is also a significant problem. Jacques Garrigue showed how you can use the newish explicit polymorphism to alleviate the problem I mentioned with the well known reference to function workaround for this problem. That's an improvement, but we still end up using mutation directly (a bit ugly, to me) and abusing the first class polymorphism a bit, just like when we use dictionary records to simulate polymorphic recursion. I'd still prefer an explict "forward" construct to handle both of these. > I think 80% of the problem for me would be solved by allowing recursive function calls. The workaround Jacques provided should satisfy this need for now. What do you think? > The next 15% would be solved by allowing types to recurse (the example you asked for is > two records that refer to each other). I think that two records that refer to each other belong in the same module :-) Seriously, I *know* that's what allowing types to recurse across modules is an example of allowing types to recurse across modules. I was searching for a compelling example of when that is necessary. In a previous incarnation of this discussion, Fergus Henderson cited some example from the Mercury compiler where the *functions* were getting huge (on the order of 10KLOC) before being split up. So that's part of a good argument for directly supporting cross module function recursion. I don't mind types getting big, partly because, IMO, a good factoring in OCaml often involves pulling type declarations into their own separate .mli file. > The next 5% is everything > else. But, I'd happily take just functions calling recursively across > modules, because that would just be huge, and allow me to refactor into > smaller modules, increasing compile speed, decoupling, etc. > > I would even be happy with this in as a temporary feature and I'd have to > rewrite code when the real thing came along. I think the reference to function trick, augmented by a naming convention (say, prefixing the funs with fwd_) and using higher order polymorphism, as JG just showed, is an acceptable workaround for now. But it doesn't seem as elegant as a forward construct. -- Brian ------------------- 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