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 EAA10148; Mon, 26 Mar 2001 04:32:09 +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 EAA10144 for ; Mon, 26 Mar 2001 04:32:07 +0200 (MET DST) Received: from mumnunah.cs.mu.OZ.AU (mail-gate.cs.mu.oz.au [198.142.254.221]) by concorde.inria.fr (8.11.1/8.10.0) with ESMTP id f2Q2VCT08793 for ; Mon, 26 Mar 2001 04:31:23 +0200 (MET DST) Received: from murlibobo.cs.mu.OZ.AU (murlibobo.cs.mu.OZ.AU [128.250.29.17]) by mumnunah.cs.mu.OZ.AU with ESMTP id MAA05439; Mon, 26 Mar 2001 12:29:11 +1000 (EST) Received: (from fjh@localhost) by murlibobo.cs.mu.OZ.AU (8.8.5/8.7.3) id MAA21709; Mon, 26 Mar 2001 12:29:10 +1000 (EST) Date: Mon, 26 Mar 2001 12:29:09 +1000 From: Fergus Henderson To: Brian Rogoff Cc: OCAML Subject: Re: [Caml-list] recursive modules redux, & interface files Message-ID: <20010326122909.A167@murlibobo.cs.mu.OZ.AU> References: <20010324043022.A19742@hg.cs.mu.oz.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.1i In-Reply-To: ; from Brian Rogoff on Fri, Mar 23, 2001 at 10:04:33AM -0800 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk On 23-Mar-2001, Brian Rogoff wrote: > On Sat, 24 Mar 2001, Fergus Henderson wrote: > > > > In the Mercury compiler, we have made significant use of module spanning > > mutually recursive procedures. For example, the code generator > > is split among several modules, roughly for each language construct > > (e.g. ite_gen handles code generation for if-then-elses, > > switch_gen handles code generation for switches, etc.), > > and since if-then-elses can contain switches (and vice versa), > > the procedures in these modules are mutually recursive. > > Interesting. A similar example occurred in a discussion in comp.lang.ml > between Matthias Blume and Greg Morrissett (concerning datatypes not > functions) where MB argued as an SML/NJ maintainer that such recurrences > were best placed in the same module and GM thought it best that they be > split even though recursive. Clearly I lean towards MB's view on this > though I take it that there are other schools of thought. > > What is your criteria for splitting the functions into different modules? Our criteria are pretty informal: each module should consist of closely related code, preferably with a single purpose that can be summed up in a concise title, e.g. "code generation for if-then-elses". In this case, I think the code was originally in a single module, but was split into sub-modules when it became too large. Here's the line counts of the relevant modules: 768 call_gen.m 1296 code_gen.m 67 commit_gen.m 324 disj_gen.m 360 ite_gen.m 283 par_conj_gen.m 1254 pragma_c_gen.m 313 switch_gen.m 897 unify_gen.m 245 dense_switch.m 549 lookup_switch.m 246 string_switch.m 1100 tag_switch.m 584 middle_rec.m ---- 8286 Generally we prefer to make modules in the range of about 200-2000 lines of code each. If a module gets much larger than that, then it tends to get a bit unwieldy, and recompilation times start to become inconvenient, so we prefer to split up modules that get larger than that. 8000 lines is definitely way too big. -- Fergus Henderson | "I have always known that the pursuit | of excellence is a lethal habit" WWW: | -- the last words of T. S. Garp. ------------------- To unsubscribe, mail caml-list-request@inria.fr. Archives: http://caml.inria.fr