Jim Balter wrote:
"Walter Bright" <[email protected]> wrote in message
news:[email protected]...
Don wrote:
Being marked as 'pure' is no guarantee that the function will terminate.
Right, and the compiler makes no attempt to check this, either.
Of course the compiler makes no attempt to check -- that *would* be the
halting problem, but there's no reason for a compiler to attempt such a
check even if it could be done.
Pure functions invoked on constant values are excellent candidates for
CTFE because they have no side effects and are computable at compile
time -- if they terminate. But pure functions that don't terminate are
almost entirely pointless;
It's a bug.
the only non-pointless example I can think of
is a kernel''s idle process on machines without an interruptable halt
instruction. Even if there were useful non-terminating pure functions,
intentionally putting the keyword "pure" on a function that doesn't
terminate is doable but dumb. Of course, unintentionally doing so is a
mistake. But dumbth and mistakes do happen, so the compiler can guard
against taking forever -- or too long, period (Ackermann's Function is a
famous example of a pure function that takes astronomically long to
compute even on small input values -- good luck on writing a compiler
that can detect such functions) -- by setting a timer. If the timer goes
off before the computation completes, the compiler should abandon CTFE
and print a warning message (unless suppressed by a pragma), since the
function is most likely buggy (this satisfies Rainer Deyke's point that
errors, including run-on functions, should be detected at compile time
rather than waiting for runtime).
I don't think you can say that it's "most likely buggy". A function to
calculate pi, for example, is a pure function that may take days to run.
