Type Inference Life Preserver

[Stuart D. Gathman]

jerry_spicklemire at my-deja.com wrote:

> The insurmountable nagging gotcha of Type
> Inference seems to be, when it doesn't, that is,
> when the best guess turns out wrong. So, with
> continuations enabled (via Stackless) would it
> now be possible to wrap an entire Type Inference
> Module in a Try that catches type errors? The Try
> would discover the type, then call back to the
> point in the "continuation" where type was
> inferred, and force the correct type!

A type failure, like an array index out of bounds failure, means that
there is a logical problem with the humans understanding of what s/he is
trying to do.  It would certainly be possible to blunder on.  For
instance, reading a non-existant array value could return a
"null" value, but it is generally better to get an exception as soon as
possible after the logic breaks down to make diagnosis easier.

Sometimes, exceptions are used for a different purpose - for instance
auto-expanding an array on a index out of bounds, or your proposal.
But this use needs to be distinguished from runtime validation of basic
assumptions.

This discussion reminds me of some conversations with sales persons
explaining to me why their store didn't carry ECC/Parity memory modules:

1) [male]  Why would anyone want parity memory?  It gets parity errors!

2) [female]  I've used non-parity memory for 2 years now, and I've
*never* gotten any parity errors!