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

[Guy Steele - Sun Microsystems Labs <address@hidden>]

   Date: Thu, 10 Jan 2002 12:49:25 -0500 (EST)
   From: Dan Weinreb <dlw@exceloncorp.com>
   To: jmarshall@mak.com
   CC: gregs@ai.mit.edu, matthias@ccs.neu.edu, stearns@curl.com, 
ll1-discuss@ai.mit.edu
   Subject: Re: cheerful static typing (was: Any and Every... (was: Eval))
   
      Date: 10 Jan 2002 12:31:00 -0500
      From: jmarshall@mak.com
   
      gregs@ai.mit.edu (Gregory T. Sullivan) writes:
   
      > Put another way, all programs, for given a static analysis, fall into
      > one of three camps:
      > 
      >   (1) Statically safe - proven to be free of runtime errors.
   
      This isn't necessarily the case.  You can have a `statically safe'
      program that `throws an exception' or `invokes the error handler' at
      runtime.
   
   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.

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.

--Guy