Small poll

[Richard A. O'Keefe]

Is it clear to everyone that

    "This code must raise an exception at run time"

and

    "This code is in error"

are different?  Let me give an Interlisp example first.

In Interlisp-D, there was a built-in function (SHOULDNT).
For example, you might define the factorial function like this:
    [PUTDQ FACTORIAL
       (LAMBDA (N)
          (IF (> N 1) THEN (* N (FACTORIAL (- N 1)))
           ELSE IF (>= N 0) THEN 1
           ELSE (SHOULDNT]
Now the call to (SHOULDNT) must raise an exception at run time,
and if the call is _executed_ that indicates an error in the way
the function is used, but it isn't an error in the program to _have_
the call sitting there.  An Interlisp compiler that rejected code
containing (SHOULDNT) would have rejected every Interlisp program I
ever wrote.

The C equivalent of (SHOULDNT) is abort().  Not, by the way, assert(0).

Is it also clear that

    "This code is obviously silly"

and

    "This code must raise an exception at run time"

are different?  Lint warns about things that are clearly silly,
yet perfectly legal, and perfectly harmless.  For example,
    x == y;
as a C statement is perfectly well defined, and quite harmless,
yet lint warns about it because you probably didn't mean it.
A C compiler which refused to compile such a program would not
be helpful, it would be buggy.

It is possible to make (=)-for-(==) and (==)-for-(=) errors in
Erlang, and lint checking for Erlang might warn about them even
though they are legal.

Whether a particular piece of apparent silliness is worth warning
about is an empirical question:  how often do programmers make the
kind of mistake that results in an instance of that pattern, and
how often do they intend it?

I have no idea what kinds of mistakes are commonest in Erlang.
It would be interesting to find out.

I've worked on a couple of compilers for languages that supported
exception handling.  (I _think_ mine was the first paper on doing this
for Prolog, except that Quintus insisted on yanking it from the conference
after it was accepted.)  Exception handling can be very tricky to get
right.  (There's a debate raging in the Clean mailing list at this moment.)
ANSI Smalltalk exception handling is a case in point; to me it seems
insanely complicated, and it's not clear that Squeak has got it 100% right
yet.  This means that especially when you are maintaining compilers, you
_need_ simple test cases which are certain to cause exceptions because
that's what you're testing.