>On Thu, 6 May 1999 17:14:34 John Meacham wrote:
>On Thu, May 06, 1999 at 09:33:15PM +0200, Bart Demoen wrote:
>> > Without optimizations this program will produce _|_ but
>> > with optimizations it will produce 3.
>>
>> wouldn't such an optimisation be called "a bug in the compiler" ?
>or a bug in the language design if it allows such things, It is my guess that
>with such powerful compile time rule rewriting you can not check for these cases
>decideably...
>....
> perhaps a weaker form of this sort of thing where lazy semantics are always
>maintained can be formulated...
Compiler optimizations are necessary in all languages and preserving
exact language semantics poses a burden that few practical compilers
can afford. In Fortran if you set x=1./0. and never use x, few
optimizing compilers will give you an overflow error. Generally, the
error behavior is the hardest property to preserve for a compiler, and
lazy semantics offer no reprieve. They may be able to deal with the
above example but not with many other highly desirable optimizations.
The optimization " n+1 > n ==> True " is extremely useful in array
subscript analysis, bounds checking etc. and is correct as long as n
terminates (is not bottom). The cases where this optimization is used
most often, n usually terminates. A more diligent compiler would use
the optimization only if it could prove that n does terminate. I will
take my chances with a fast but less diligent optimizing compiler
which in some diabolical cases produces 3 when it should not have
terminated.
Both the Id compiler and now the pH compiler follow this philosophy.
May be we should let an implementation do whatever it pleases in case
of an error. If we regard non-termination as an error then producing a
value in case of non-termination may not seem so bizarre. However,
there are many cases where I really do want my errors reported. I
think such compiler/language decisions should be taken on pragmatic
grounds.
Arvind
