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 WAA00117; Mon, 17 Mar 2003 22:13:25 +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 WAA00152 for ; Mon, 17 Mar 2003 22:13:24 +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 h2HLDNX15809 for ; Mon, 17 Mar 2003 22:13:23 +0100 (MET) Received: (qmail 87016 invoked from network); 17 Mar 2003 21:13:21 -0000 Received: from arda.pair.com (HELO compaqreview.d6.com) (209.68.1.133) by relay.pair.com with SMTP; 17 Mar 2003 21:13:21 -0000 X-pair-Authenticated: 209.68.1.133 Message-Id: <4.3.2.7.2.20030317123042.038b00c0@localhost> X-Sender: checker@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 17 Mar 2003 13:09:10 -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.20030317110310.0451dfa0@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 quirks:01 annoys:01 decoupling:01 coupling:01 misses:01 subtlety:01 initialized:01 implemented:01 fabrice's:01 selm:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk >I also use OCaml in my job. By "pet problem", I meant that set of language >quirks that annoy you. If you work with even one other OCaml programmer, >I'll bet you find that what annoys you may not annoy the other guy as >much, and vice versa. Sure, I was just indicating that there are some things that go beyond "pet problems" and get into "real problems", and I think this is one of them. The question is just whether programming is enough of an engineering discipline to be able to say "this is a quantifiably bad thing for implementing large programs". I guess it's not since things like this are still very subjective, but if it was then I'd say this function thing falls into that category because you want to enable decoupling. It's also gray because compile times and coupling aren't going to kill a project, they're just going to make the process more painful than it needs to be. So, the rationalizers always can point to success and say, "see, it wasn't needed", which misses the subtlety of the situation. > > and there are order of initialization issues (which there aren't if you > just > > allow functions to be called, and not arbitrary values) >Are you sure? I think the order of initialization issues still occur even >if you just allow functions. Hmm. There are no "0th order" initialization order problems, since a function is always just callable (as opposed to trying to call through an uninitialized value). I guess there are 1st order problems in that if A calls into B.f and B hasn't been initialized and B.f uses a global in B then you'll be in trouble. I don't think there's a problem if you do not reference any globals, though. I think it's still a valuable tool in that case, but yeah, I guess it's not totally safe. That's probably why this hasn't been implemented. I wonder what that patch did in this case, if anything. Ah, here's Fabrice's original post, and it looks like you have to enforce the constraint manually: http://groups.google.com/groups?selm=fa.hlh6e5v.1fmkppq%40ifi.uio.no (related post by Xavier, replying to me complaing about this limitation in 2001 when I learned about it :) http://groups.google.com/groups?selm=fa.dks4ugv.1a6iho7%40ifi.uio.no >Again, I agree, but every language has annoying flaws. Sure, but again, there has to be some metric for when something is more than just an annoying flaw. I guess large programs get written in caml, so by some measure it "works". Maybe that is the only metric available at this point. However, given that metric, large programs got written in asm, but that didn't stop people from trying to fix the "annoying flaws" and finding value in fixing them. :) >Actually, I've read some SML programmers arguing exactly that, that it is >a limitation leading to better designs, and that allowing the types and >functions to be spread out will lead to more bad designs. Good SML >programmers too. My opinion is closer to yours than theirs wrt functions, >but I wouldn't just discount that opinion as nonsense. I don't discount it as nonsense, I just trust professional programmers more. We're so far away from a language that actually helps design programs for you, that any steps in that direction right now are usually naive and more limiting than useful, in my opinion. Caml needs Obj.magic, for example. It would be a less viable language without it, even though every argument for its use could be called "bad design". 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