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 AAA04074; Fri, 23 Jul 2004 00:42:12 +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 AAA04151; Fri, 23 Jul 2004 00:42:11 +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 i6MMg8SH027729; Fri, 23 Jul 2004 00:42:10 +0200 Received: from [192.168.1.200] (ppp205-61.lns1.syd3.internode.on.net [203.122.205.61]) by smtp1.adl2.internode.on.net (8.12.9/8.12.9) with ESMTP id i6MMg54Y032206; Fri, 23 Jul 2004 08:12:05 +0930 (CST) Subject: Re: [Caml-list] kprintf with user formatters From: skaller Reply-To: skaller@users.sourceforge.net To: Pierre Weis Cc: Jon Harrop , caml-list In-Reply-To: <20040722173901.A18239@pauillac.inria.fr> References: <200407211552.RAA04351@pauillac.inria.fr> <200407212141.45191.postmaster@jdh30.plus.com> <20040722173901.A18239@pauillac.inria.fr> Content-Type: text/plain Message-Id: <1090536125.5870.150.camel@pelican.wigram> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4) Date: 23 Jul 2004 08:42:05 +1000 Content-Transfer-Encoding: 7bit X-Miltered: at concorde with ID 410042C0.001 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Loop: caml-list@inria.fr X-Spam: no; 0.00; caml-list:01 kprintf:01 formatters:01 sourceforge:01 2004:99 pierre:01 weis:01 conforming:01 aas:99 9660:01 glebe:01 compiler:01 compiler:01 semantics:01 evaluates:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk On Fri, 2004-07-23 at 01:39, Pierre Weis wrote: > For instance, you would have a hard time to persuade a > matematician that > > 0 * ln (0) > > is well-defined and evaluates to 0, ``because ln (0) has not to be > considered at all given the left operand''. Actually, this IS the case in many languages such as C. 0 is not in the domain of ln. Therefore, the result is undefined when you apply ln to 0 because you're applying a function to a value outside its domain. In language standards it is sometimes said that the result is undefined in such cases, which means that the compiler can generate code to do anything it wants in such cases. In particular it can return 0 and remain conforming and therefore it can apply the shortcut evaluation. This is NOT the case if the language standard specifies an exception must be thrown, or NaN or +Inf returned, which is generally a very bad idea precisely because it makes the semantics determinate and thus defeats the optimisation which could otherwise be obtained by using the usual mathematical law 0 * x = 0. C is very careful to leave lots of things undefined. This issue actually arose directly on the C++ Standards Committee, except the function was division not ln. The question was whether a compiler was allowed and/or required to issue a diagnostic error message given: main() { return 1/0; } Note that it is possible to prove IN THIS CASE that the program will always fail by dividing by zero. However, it isn't always so obvious -- so you simply cannot require a diagnostic. Indeed, one can argue -- and someone DID argue -- that even if the program always fails when executed .. who knows if it is executed? The code must be generated, C compiler can issue a warning but it is NOT allowed to reject the program. It must actually generated code which can be executed .. even though that code can do anything (Aas far as I can remember that was the interpretation..) -- 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