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 TAA17443; Tue, 11 Jun 2002 19:45:06 +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 TAA17461 for ; Tue, 11 Jun 2002 19:45:05 +0200 (MET DST) Received: from TheWorld.com (pcls4.std.com [199.172.62.106]) by concorde.inria.fr (8.11.1/8.11.1) with ESMTP id g5BHj4H22996 for ; Tue, 11 Jun 2002 19:45:04 +0200 (MET DST) Received: from watergate.world.std.com (pool-141-154-28-212.bos.east.verizon.net [141.154.28.212]) by TheWorld.com (8.9.3/8.9.3) with ESMTP id NAA04408 for ; Tue, 11 Jun 2002 13:45:03 -0400 Message-Id: <5.1.0.14.0.20020611133017.027fe7d8@pop.theWorld.com> X-Sender: chase@pop.theWorld.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 11 Jun 2002 13:44:59 -0400 To: caml-list@inria.fr From: David Chase Subject: Re: [Caml-list] Catching exceptions into strings In-Reply-To: <20020611173726.A14277@pauillac.inria.fr> References: <5.1.0.14.0.20020611092123.027cbb48@pop.theWorld.com> <20020611092333.GJ7647@adelscott.lanetcie.com> <5.1.0.14.0.20020611092123.027cbb48@pop.theWorld.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk At 05:37 PM 6/11/2002 +0200, Xavier Leroy wrote: >> where it happens to be necessary, and optimizing it out when it is not? > >I'm more skeptical here. I'm yet to see a practical compile-time >analysis that can prove that an integer expression is not zero in any >but the most trivial cases (the expression is a constant or a for-loop >index). (By "integer", I mean machine integers with modulo arithmetic.) Trivial is pretty common, and for-loop index is an important common case. A "constant propagation" lattice can also be a good deal more interesting than just constants. I've worked on a compiler that propagated information about type inference, null/not, relationship to various array bounds, positive/negative/zero/not, and a friend and I have discussed the usefulness (not the feasibility, which is dead-simple) of propagating information about set/cleared/smeared bits. It is plausible, if you are working in the absence of reflection, that a compiler might infer the non-zero-ness of array elements and object fields. If, on the other hand, you are working in a world where programs have reflective access to data, then all bets are off (as in, once upon a time, and maybe still, the native code in java.lang.sql went out and fiddled with the private fields of strings, and I know of people at a Famous Computer Company who wrote native code that twiddled the private fields of Java file-related classes in order to get a sort of poor man's asynchronous I/O.). I've also learned to be incredibly skeptical about any programmer's assertion that "X cannot possibly happen", and throwing an exception means that you can at least talk about what happens when X does happen. Just for instance, a server program can be written to catch any exception at the "outside" of a service thread, and report it both to the web page and the debug log, and then continue running as before. This is much better than the server falling over and needing a restart. One approach to this problem, though I don't know if anyone has seriously tried it, would be to ask the programmer to supply the missing proof steps, and if those steps connect the dots, then the checks come out. This does require a cleverer proof engine in the compiler, but I'd trust that a lot more than just believing some claim that I read in a comment or a build script. And lastly, what does it cost to do the check? Surely, you did not omit the check in the name of efficiency (he says, smirking) without first measuring the cost? That would be (ahem) premature optimization, which is well-known as the root of all evil. :-) David Chase ------------------- 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