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 RAA18684; Wed, 7 Apr 2004 17:51:37 +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 RAA18655 for ; Wed, 7 Apr 2004 17:51:36 +0200 (MET DST) Received: from smtp1.adl2.internode.on.net (smtp1.adl2.internode.on.net [203.16.214.181]) by nez-perce.inria.fr (8.12.10/8.12.10) with ESMTP id i37FqQjq025444 for ; Wed, 7 Apr 2004 17:52:28 +0200 Received: from [192.168.1.200] (ppp116-94.lns1.syd2.internode.on.net [150.101.116.94]) by smtp1.adl2.internode.on.net (8.12.9/8.12.9) with ESMTP id i37FpLKg087424; Thu, 8 Apr 2004 01:21:23 +0930 (CST) Subject: Re: [Caml-list] Function forward declaration? From: skaller Reply-To: skaller@users.sourceforge.net To: Richard Jones Cc: caml-list In-Reply-To: <20040407141519.GA6618@redhat.com> References: <60532B15DF92FD4693AA89B2F7E01D8F013F29EC@tmex02> <00cf01c41bd6$391b53a0$0203a8c0@hoedic> <20040406175320.GA19840@redhat.com> <1081279717.16531.6.camel@qrnik> <002901c41c65$b53e4c50$19b0e152@warp> <1081345936.19232.579.camel@pelican> <20040407141519.GA6618@redhat.com> Content-Type: text/plain Message-Id: <1081353080.19232.678.camel@pelican> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) Date: 08 Apr 2004 01:51:21 +1000 Content-Transfer-Encoding: 7bit X-Miltered: at nez-perce by Joe's j-chkmail ("http://j-chkmail.ensmp.fr")! X-Loop: caml-list@inria.fr X-Spam: no; 0.00; caml-list:01 sourceforge:01 2004:99 2004:99 avoiding:01 idioms:01 passing:01 debugging:01 recursion:01 tradeoff:01 expressivity:01 expressivity:01 'real:01 intermodule:01 recursion:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk X-Status: X-Keywords: X-UID: 94 On Thu, 2004-04-08 at 00:15, Richard Jones wrote: > On Wed, Apr 07, 2004 at 11:52:17PM +1000, skaller wrote: > > IMHO it isn't forward calling that is broken, > > but global variables. > > A somewhat controversial viewpoint ... While minimising the use of > global variables might be a theoretical desirable goal, they are very > useful when you're actually writing real programs under the schedule > pressure for real users.. This may be the case with a poorly designed program, or a programmer not practiced in the techniques of avoiding them. Since people must work with others, one is bound to run into this problem. However, if you write your code to be reentrant from scratch, and do so regularly, you soon learn the idioms required, and soon enough the benefits of explicitly passing values around will reward you, and everyone who works with your code. At least, that is my experience. I allow myself to use global variables only for debugging. And I get a bit annoyed when system software isn't reentrant -- for example AFAIK Ocamlyacc parsing engine uses global data, which is very annoying because I actually have a need for recursive parsing and I cannot do it: I'm forced to build temporary data structures to defer the recursion. > The trouble seems to be that I have a perfectly practical and > reasonable desire to see prototypes added to the language, because, > believe it or now, it helps to solve some problems in the Real World. I'm familiar with the Real World :D > Now if there's some deep reason why it's actually impossible I would > understand, but plenty of other languages (eg. C) seem to have > prototypes and they get along just fine. But they don't. There is a tradeoff between static assurance and expressivity. Ocaml errs on the side of providing stronger guarrantees at the expense of some loss of expressivity. I believe that a large class of 'real world' problems where you would use prototypes can be solved in a slightly different way, by allowing some limited form of intermodule recursion. The Ocaml team is working on that Right Now. The CVS version of Ocaml supports some intermodule recursion, but only within a single compilation unit. If that proves successful I believe the team will start work on extending the facility to recursion across compilation unit boundaries. If all goes as one hopes, this should increase the expressivity of the language: the cost will be that some error checks are defered to initialisation time. That is a reasonable compromise since with simple enough initialisation one would expect a single test to find all errors immediately. > (Same, by the way, goes for a 'return' statement which OCaml is crying > out for). I don't think it makes any sense in Ocaml. I'd like to explain why, by first explaining that Felix *does* have an explicit return statement. In Felix, there is a syntactic distinction between statements and expressions. There is a semantic difference too: statements may have side effects, expressions may not. Within a function, you can use statements provided the side effects don't propogate outside the function's closure. Syntactically, because a function is made up of imperative statements, there must be an explicit return statement. In Ocaml, expressions can have side effects. So there is no need for a syntactic category other than expressions for executable code. So a return statement would be impossible syntactically, it would have to be a return *expression*. It is easy to define: here it is: let return x = x and you can use it wherever you want. -- John Skaller, mailto:skaller@users.sf.net voice: 061-2-9660-0850, snail: PO BOX 401 Glebe NSW 2037 Australia Checkout the Felix programming language http://felix.sf.net ------------------- 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