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 UAA30564; Mon, 17 Mar 2003 20:38: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 UAA30447 for ; Mon, 17 Mar 2003 20:38:12 +0100 (MET) Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by nez-perce.inria.fr (8.11.1/8.11.1) with SMTP id h2HJcBX12976 for ; Mon, 17 Mar 2003 20:38:12 +0100 (MET) Received: (qmail 52120 invoked from network); 17 Mar 2003 19:38:08 -0000 Received: from arda.pair.com (HELO compaqreview.d6.com) (209.68.1.133) by relay.pair.com with SMTP; 17 Mar 2003 19:38:08 -0000 X-pair-Authenticated: 209.68.1.133 Message-Id: <4.3.2.7.2.20030317110310.0451dfa0@localhost> X-Sender: checker@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 17 Mar 2003 11:33:49 -0800 To: brogoff@speakeasy.net From: Chris Hecker Subject: Re: Module recursion (Was Re: [Caml-list] Re: Haskell-like syntax) Cc: "caml-list@pauillac.inria.fr" In-Reply-To: References: <4.3.2.7.2.20030316205959.045990d8@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam: no; 0.00; hecker:01 checker:01 recursion:01 caml-list:01 haskell-like:01 kloc:01 refactor:01 slower:01 framerate:01 annoyances:01 jacques:01 stuffing:99 error-prone:01 redesigned:01 shove:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk >I think any disagreement was more one of degree, in that my "pet >problem(s)" are not prioritized the same way yours are. I actually don't see this as a "pet problem" thing. I'm trying to write a real shipping application in ocaml (currently 13kloc and will probably be 4x that at ship, not the largest app ever written to be sure, but certainly not a test app). Not allowing recursion makes it harder to refactor and improve compile times, which is not a good thing for process (especially since the native compiler is a bit pokey (6x slower than a C++ compiler for same LOC last time I checked), and my app can't run bytecode because the framerate is too low). It's also something that just flabbergasts professional C++ programmers when they look a caml...the concept that you can't break up a compilation unit any way you want to save compile time or to make it more readable is crazy to them, and they're right. I've already committed to using caml for this project and will see my experiment through to ship, so these things are just "annoyances" that just go in the "cons" column in the article I'm going to write at the end. For somebody not as committed to trying it as me, they're probably showstoppers and they'll decide not to use caml. > > 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 "id" thing he showed? That's just the same as doing a ref option and then stuffing the functions, isn't it? Anyway, it's an ugly hack, it spreads knowledge of what one module needs from another explicitly into the interface, you have to explicitly type the forward functions, it requires an error-prone manual stuffing step, and there are order of initialization issues (which there aren't if you just allow functions to be called, and not arbitrary values) if I undertstand it correctly. Basically, this workaround is not making a professional programmer looking at ocaml feel better about using it for large projects, in my opinion. >I think that two records that refer to each other belong in the same >module :-) The reason I didn't bother giving an example is that out of context any example can be "redesigned by the list" to not need it, or the list can claim that you can just shove things in the same module. I think this is a case of good old "you don't need that" syndrome, which computer people fall prey to all the time. Somebody's favorite thing doesn't support X, so many bytes will be sacrificed convincing the other person that they don't need X. It's a pretty big waste of time, in my opinion. The ability to have two types refer to each other is a totally reasonable thing to do, and if you agree that it's reasonable (which you seem to), then the ability to have them in different files is also reasonable by extension. The limitation that they have to be in the same file is just that, a limitation. It's not a feature leading to better design, or any other rationalization like that. >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. Define "for now". You have to decide when the workaround is doing more damage to the cause of making ocaml viable/more popular/whatever your goal is. If it reduces pressure for a real solution, but you still have to explain the workaround with a straight face to every person who asks why their 4 line a.ml+b.ml example won't link with this fancy new "high level language" but their crappy C compiler can do it, then it's not clear to me that it's a win. The other thing is that something crazy like the mixin modules thing will incur runtime overhead to do the module creation at init time, where you just don't need that to call functions, so there are arguments for adding this even if you plan to do mixins in the long run. But anyway, I doubt I've convinced anybody on the other side of the fence. 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