Re: cheerful static typing (was: Any and Every... (was: Eval))

[Robert Bruce Findler <address@hidden>]

Quoting Guy Steele - Sun Microsystems Labs:
>    You should not equate "runtime error" with "throws an exception".
>    Some errors do not throw exceptions, and some throws of exceptions are
>    not errors.  An error is when a program fails to meet its defined
>    contract.  If you call integer divide on 2 and 0, and it throws a
>    zero-divide exception, that's not an error, because integer divide
>    is obeying its contract.
>    ...
> 
> Careful, here, Dan; taking this to a logical extreme
> implies that, if you beef up the contracts, you can
> define away all errors.

It is certainly possible to make vacuous contracts that guarantee
nothing about your operation. In fact, there is one function having
that contract that I program with routinely, as a program environment
developer. It's `eval'. DrScheme (our PE) has a REPL; it reads
characters from the input, forms an s-expression from them and `eval's
it. Since eval can do just about anything, DrScheme has to handle just
about anything and report back what happened to the user of the PE.

Of course, that is not a useful contract in most cases. :)

> Maybe we could say that a run-time error is a situation
> in which a program exhibits one of a set of behaviors
> that we choose to describe as "undesirable"?  Often
> throwing one of a certain set of exceptions is considered
> undesirable; indeed, the division-by-zero exception may
> be undesirable in some contexts despite the fact that
> it's in the contract of the "/" operator.

I think that what's missing here is the idea of blame. For each
contract violation there must be a guilty party and they are to be
blamed for the violation.

It is important to say that raising a divison-by-zero error is part of
the division operator's contract, so that we know that when the
exception is raised we should not blame `/'. Instead, there is some
other operation that uses `/' whose contract does not say anything
about divison by zero errors (eg, a line drawing function that may not
handle vertical lines properly). That's the one to blame.

Robby

PS: As this is my first post, let me take this chance to say that I
have really enjoyed the discussions on this list and that I wish that I
had been able to attend the workshop. Thanks very much!