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 KAA07370; Tue, 27 Mar 2001 10:21:29 +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 KAA07366 for ; Tue, 27 Mar 2001 10:21:28 +0200 (MET DST) Received: from tcs.inf.tu-dresden.de (tcs.inf.tu-dresden.de [141.76.75.101]) by nez-perce.inria.fr (8.11.1/8.10.0) with ESMTP id f2R8LRT25562 for ; Tue, 27 Mar 2001 10:21:27 +0200 (MET DST) Received: from ithif51 (ithif51 [141.76.75.51]) by tcs.inf.tu-dresden.de (8.11.1/8.11.1) with ESMTP id f2R8LR507825 for ; Tue, 27 Mar 2001 10:21:27 +0200 (MET DST) Received: from tews by ithif51 with local (Exim 3.12 #1 (Debian)) id 14hojD-0006jU-00 for ; Tue, 27 Mar 2001 10:21:23 +0200 From: Hendrik Tews MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: OCAML Subject: Re: [Caml-list] recursive modules redux, & interface files In-Reply-To: <20010322140157.A7070@miss.wu-wien.ac.at> References: <4.3.2.7.2.20010318142842.00d85300@shell16.ba.best.com> <20010321194138.A29405@pauillac.inria.fr> <20010322140157.A7070@miss.wu-wien.ac.at> X-Mailer: VM 6.34 under Emacs 20.7.2 Message-Id: Date: Tue, 27 Mar 2001 10:21:23 +0200 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk Hi, Markus Mottl writes: From: Markus Mottl Date: Thu, 22 Mar 2001 14:01:57 +0100 Subject: Re: [Caml-list] recursive modules redux, & interface files Hendrik Tews schrieb am Thursday, den 22. March 2001: > I would like to vote for solutions that work for the common case > when writing large programs, even if they are hacks, considered > from a theoretical point of view. I am not so fond of sacrificing theoretical beauty: it usually seems to be the case that there are working solutions that are also elegant - it's only a matter of thinking about them long enough. You might speed up development a bit by allowing hacks if you cannot immediately find a sound solution, but IMHO it is hardly ever a good idea in the long run. [As an aside: In principle I do not agree that usually there exist elegant solutions. This would imply that for most problems there are elegant solutions, whereas the attribute elegant can only apply to a small subset of all solutions (unless everything is elegant). ] But for the main problem of mutual recursion: I would also appreciate a theoretically nice solution. But ocaml and its predecessors have been around now for long time, so it seems that it is not that easy to find a good solution for mutal recursion between modules. So instead of waiting another three years I would prefer a solution now, even if it is intermediate and not so clean. If there is a problem with expressiveness or else, it seems to be better to first try harder to find a solution with the existing system before crying for a hacky extension. And if this doesn't work, let's try to find a more expressive theory rather than abandoning theory completely. I agree, don't let's abandoning theory. But let's make a few compromises, where a good solution is not available in the near future. Nearly everytime I had thought "now I need recursive modules", I found other, even elegant ways to do it. I know, with some effort you can put every system in a linear structure and avoid module spanning recursion. But I do not want to restructure the whole project, only because I need some recursive functions. The more important point is that in a project with several people the overall complexity of the system structure must stay below a certain limit. If you create a system structure that is above this limit, then the project will fail. > [duplications in signatures and structures] The solution to put the whole signature into a separate .ml-file requires hardly any work and solves this problem neatly. Why introduce a kludge if there are reasonable ways to do it? I have the same argument here. Keeping three files instead of two is more complex. As a programmer you have to pay for this complexity and it doesn't buy you anything. The result is that people do not write interfaces because they do not like the additional effort it requires. Bye, Hendrik ------------------- To unsubscribe, mail caml-list-request@inria.fr. Archives: http://caml.inria.fr