Re: Should compilers elide errors when possible?

On Dec 22, 9:03 am, Tim Bradshaw <tfb+goo...@xxxxxxxx> wrote:
However "no side effects" is an interesting question which is often
over simplified. Consider this:

(progn (sleep 10) (do-something))

Well, with an obvious definition, SLEEP has "no side effects".

Obviously it does have a side effect: it inserts a pause of some
hopefully more or less reliable duration between some previous side
effect and a future side effect. Timing of externally visible effects
is important, and is itself an effect.

Except
it does: it waits for 10 seconds, and that's a very important real-
world side-effect.

(progn
(sleep 10) ; give user time to panic and interrupt
(do-something)) ; bounce system

I'd be pretty unhappy if the compiler elided that call to SLEEP.

Thinking of it this way, failure to halt is a pretty serious side-
effect.

Halting by infinite loop is a /defect/, not an /effect/.

If the compiler detects an infinite loop which contains on side
effects, it should replace it with (error "infinite loop detected").
Or at least a compile-time diagnostic.

The only piece of code in a system which has a right to halt by means
of spinning the CPU is something deep in the operating system for
handling a system halt (or a CPU halt for hot-swapping).

You'd want to handle this type of halt not necessarily by a naive loop
in the high level source code, but by taking advantage of whatever
instruction set feature is available for doing a proper halt.

E.g. on the Motorola 68000, you might write a loop around the STOP
instruction.

That instruction, by the way, is privileged. Good reason for that;
halting the machine needs to be virtualized. If a guest virtual OS
performs a proper STOP, the host OS gains control and suspends only
the guest OS. If the guest OS performs a stupid infinite loop, the
host OS suffers!

(defun forever () (loop))
(if (forever) (set-off-the-bomb) (set-off-the-bomb))

I'd kind of like it to be the case that a responsible compiler did
*not* elide that call.

The programmer is responsible here, not the compiler.

What about:

(if (forever)
(disarm-bomb)
(disarm-bomb))

What is the ``esponsible'' thing for the compiler to do now?

Moreover, what if setting off the bomb is a good thing, and disarming
it is a bad thing? Without more information, we don't know whether the
bomb blowing up is good or evil. What if the bomb is embedded in an
asteroid that is headed for a populated planet? :)

Finally, if it's really, really important that the machine halt at
some point, shouldn't that have been tested?

So I think that really this is a subtle question. In my view a
compiler should elide code only if it can prove no side effects, where
"side effects" include intentional real-world side-effects, such as
pausing the program (and many other things), and in particular where
it can prove that the code halts.

What should it do if it can't prove that the code halts? And should
the performance of a side effect depend on what the compiler can and
cannot prove?

There are lost of examples of side-effect-free code that you might
want to elide during optimization, for which termination cannot be
proved. Any such code could be regarded as a potential infinite loop
in disguise which must be preserved. That suspicion then interferes
with legitimate optimization.

I would say that only the use of valid interfaces for halting the
program should be considered as expressing the true intent to halt:
making a halting system call, or executing some special instruction.

Since SLEEP is a side effect that can't be elided, then a good way of
halting would be (LOOP (SLEEP 42)).

One real-world side effect is exhausting the system's resources. For
your definition of FOREVER I find it hard to see that it would not do
that, because of the (* 2 (forever)) - either that's going to burst
the stack, or it's going to get a bignum overflow at some point I
think. If it does not do that, then it fails to halt, and I think
that is a side-effect (by my definition) for sure.

Everything that happens in the machine can be regarded as a side
effect. What we do is we separate the inessential or undesireable
ones (the ``bad'') from the necessary, useful ones (the ``good'').

It's a bad side effect that computation takes time and energy. We'd
like computation to take zero time and energy. That's not realistic,
but we can reduce the time, which we call optimization. To that aim,
we reorganize code, invent better algorithms and make faster
hardware. Storage use can be regarded in the same way; it is ineed a
real-world bad side effect that storage is required and that it can be
exhausted. We'd like a program to use less space, all else being
equal.

Since the use of computational time is regarded as a bad side effect,
then an endless loop (not based around a formal halting instruction)
is considered so bad that it's actually a defect!

These days, users have operating systems which can juggle multiple
processes and tell them how much CPU time each one is taking. If your
program hits 100% CPU while obviously doing no useful computational
work, users will report this as a bug. It's not uncommon even for
users without a computing background know that this is ``bad''.

So I think these questions are very subtle in general, and working
from some theoretical model of computation does not tell you the
useful answer to give.

That's right; you have to work from a model where you take into
account the role of the computer in the rest of the world: its
purpose, its resource limitations, how it fits into human values, etc.
.