English version
Accueil     À propos     Téléchargement     Ressources     Contactez-nous    

Ce site est rarement mis à jour. Pour les informations les plus récentes, rendez-vous sur le nouveau site OCaml à l'adresse ocaml.org.

Browse thread
[Caml-list] Catching exceptions into strings
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2002-06-11 (17:45)
From: David Chase <chase@w...>
Subject: Re: [Caml-list] Catching exceptions into strings
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