🚀 go-pugleaf

> ... I am not sure about you, but I would rather have a program that runs
> faster, and in one chance in a couple thousand `goes down in flames' than a
> program that runs slower and in one chance in a couple thousand
> says something to the effect: `FATAL: array overflow'...
> Also, I think your analogy is a bit off. `My boats DONT sink',  8->
> therefor, why WASTE money on lifeboats? :-)
> -- 

Suppose your CAD program for nuclear-powered boats has the error-checking
turned off.  So instead of `FATAL: array overflow' some data is corrupted
(without any indication) and you go ahead and build the boat, which 
promptly sinks.

One chance in a couple thousand is not good enough.  I think most of the
checks causing significant slowing could be verified by static analysis
at compile time and the run-time check not inserted.  E.g. some simple
range analysis could show many subscript-checks are provably unnecessary.
Presumably its only a few checks in the inner-most loops that cause the 
program to run signifcantly slower.

There's some papers on range analysis in: 

	Program Flow Analysis: Theory and Applications
	Steven S. Muchnick & Neil D. Jones
	Prentice-Hall, Inc.
	Englewood Cliffs, New Jersey
	1981

Arch D. Robison					robison@uiucdcs
University of Illinois at Urbana-Champaign