"Don" <nos...@nospam.com> wrote in message
news:i2ice7$2i7...@digitalmars.com...
Jim Balter wrote:
"Walter Bright" <newshou...@digitalmars.com> wrote in message
news:i2flvi$4i...@digitalmars.com...
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.
Yes, that was my point (I gave below the sole exception I'm aware of).
That's why the fact that the pure keyword doesn't *guarantee* that the
function terminates is irrelevant. In fact, the language could specify that
a function marked "pure" must terminate and say that it's an error (which
may or may not be detected by the compiler) if it does not.
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.
I just mentioned Ackermann's function above, so obviously I am aware that
pure functions *can* take a very long time -- and that's a case where an
exact result can be computed in a finite amount of time, unlike a complete
decimal expansion of pi. However, in the real world, it's quite unlikely
that a pi calculator would be a pure function operating entirely on constant
values (required for CTFE) that takes days to run -- in reality, the number
of iterations or significant digits is variable, intermediate results are
printed or stored (possibly memoized), short-lived pure functions are
invoked by non-pure frameworks, multiple threads coordinate the work, etc. I
DO think I can say that long-running pure functions are *most likely* buggy,
which is not contradicted by anecdotal counterexamples. But such a Bayesian
debate is not worth our time having; as I mentioned elsewhere, there could
be a noctfe pragma for functions the programmer does not want the compiler
to attempt to compute, and one could also leave it up to the programmer to
specify whether they want to be warned about attempts to compute pure
functions that take longer than some threshold to compute -- which would
satisfy Rainer Deyke's desire to learn about (possible) bugs at compile time
rather than waiting for run time.
