Re: Should compilers elide errors when possible?

On Dec 22, 2:12 am, Ray Dillinger <b...@xxxxxxxxx> wrote:


Should it also be legal for a compiler to emit code that
simply returns 2 (from the if expression), or should the
programmer be able to _rely_ on a function like forever
to transfer flow of control to an exception handler?

This problem is obviously not soluble in general because it's the
halting problem.

However, in the specific case where a compiler can prove that there
are no side-effects of a function and its result is not used, then it
certainly generally ought to be OK to elide calls to it.

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". Except
it does: it waits for 10 seconds, and that's a very important real-
world side-effect. If I put the comments back in to this code, we can
see why:

(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. So (for a modified definition)

(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.

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.

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.

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.

--tim

No hyphens were harmed in the production of this message
.

Relevant Pages

  • Re: Should compilers elide errors when possible?
    ... Well, with an obvious definition, SLEEP has "no side effects". ... I'd be pretty unhappy if the compiler elided that call to SLEEP. ... it should replace it with (error "infinite loop detected"). ... The only piece of code in a system which has a right to halt by means ...
    (comp.lang.lisp)
  • Re: [EGN] Hoisting Loop Invariants (Was: Re: [EGN] Numerical Accuracy)
    ... compiler out there somewhere that did as you claim. ... > the programmer has this knowledge, then the programmer should not use ... >> string in a loop, regardless of the blatant inefficiency of doing so. ...
    (comp.programming)
  • Re: The Philosophy of Programming?
    ... A compiler is free to ... >>is to allocate on entry to almost any block. ... > int foo{ ... But any programmer who wants to be more than a coder prefers, I think, ...
    (comp.programming)
  • Re: Brian Kernighan, maybe Im not worthy, maybe Im scum
    ... what experienced programmers do, ... the compiler doesn't have the free pass to /assume/ that the function ... Nobody has recommended doing all optimization by hand to my knowledge. ... Compiler behavior in optimization simply has no place in a language ...
    (comp.programming)
  • Re: Static/Strong/Implicit Typing
    ... and every programmer would instantly revere the static type analysis. ... will inform your compiler of your construction. ... the two varieties and consciously break the type disjointness. ... Common Lisp is not quite as abstract, ...
    (comp.lang.lisp)