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 RAA15483; Wed, 7 Apr 2004 17:13:17 +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 RAA15389 for ; Wed, 7 Apr 2004 17:13:16 +0200 (MET DST) Received: from smtp1.adl2.internode.on.net (smtp1.adl2.internode.on.net [203.16.214.181]) by concorde.inria.fr (8.12.10/8.12.10) with ESMTP id i37FDDYM008126 for ; Wed, 7 Apr 2004 17:13:14 +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 i37FCmKg031949; Thu, 8 Apr 2004 00:42:49 +0930 (CST) Subject: Re: [Caml-list] Function forward declaration? From: skaller Reply-To: skaller@users.sourceforge.net To: Ville-Pertti Keinonen Cc: skaller@users.sourceforge.net, Nicolas Cannasse , "Marcin 'Qrczak' Kowalczyk" , caml-list In-Reply-To: <3B300570-889F-11D8-A3FA-000393863F70@exomi.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> <3B300570-889F-11D8-A3FA-000393863F70@exomi.com> Content-Type: text/plain Message-Id: <1081350767.19232.638.camel@pelican> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) Date: 08 Apr 2004 01:12:47 +1000 Content-Transfer-Encoding: 7bit X-Miltered: at concorde 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 archaic:01 run-time:01 unsound:01 initialiser:01 inverted:01 expressive:01 initialise:01 model:01 marshalling:01 marshalling:01 9660:01 glebe:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk X-Status: X-Keywords: X-UID: 93 On Thu, 2004-04-08 at 00:24, Ville-Pertti Keinonen wrote: > On Apr 7, 2004, at 4:52 PM, skaller wrote: > Minor nit - you probably mean "idle thread"...and it really isn't > currently common in the above form, since most modern CPUs That may be true, but 99% of all real time code is executed on archaic processors because of the price tag (we're talking instrumentation and device control and $1 parts here .. ) > I'd expect (but haven't attempted to prove) detecting uninitialized > values to be equivalent to the halting problem, so there would > inevitably be cases that would need to be rejected, detected at > run-time or result in unsound programs. I suspect you are right for a totally unconstrained language, whatever that means. However clearly, this isn't the case for a constrained language: uninitialised values are impossible in Ocaml as it stands and any fault is detected immediately by the parser :D I don't know the exact algorithm, but Java allows a variable to be declared without an initialiser, provided it is 'manifestly assigned before use'. That condition is reputedly easy to check by both machine and human. Of course, Charity guarrantees termination, so with the constraints it imposes the halting problem itself is easily solved (it isn't Turing complete). Perhaps then, your observation needs to be inverted to a question: what is a reasonable balance between expressiveness and error trapping? The Ocaml solution is least expressive, and its STILL fails to catch all errors because sometimes programs have to 'cheat' the system by using the wrong type for a variable, or a wrong value to initialise it, or even Obj.magic (eg: variable length array cannot be defined in Ocaml without cheating). Still, I personally find most code can be organised so the number of initialisation tricks is quite small and not too offensive: there is just one I'm aware of in Felix. That particular case isn't a result of the Ocaml language per se, but its compilation model. There is a record containing the build number, which changes every compilation, the record is compiled last to avoid full recompile every time, and so can't be accessed by the rest of the system. So an 'uninitialised variable' is used which is compiled first, and the last initialisation the program does is to store the build number constant into the variable. That build number is used when Marshalling data, to allow a check the same version of the binary creates and reads the data: I don't do any marshalling during "initialisation" .. :D -- 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