D's treatment of values versus side-effect free nullary functions

[Rainer Deyke]

On 7/24/2010 15:34, Jim Balter wrote:
> The point about difficulty goes to why this is not a matter of the
> halting problem. Even if the halting problem were decidable, that would
> not help us in the slightest because we are trying to solve a
> *practical* problem. Even if you could prove, for every given function,
> whether it would halt on all inputs, that wouldn't tell you which ones
> to perform CTFE on -- we want CTFE to terminate before the programmer
> dies of old age. The halting problem is strictly a matter of theory;
> it's ironic to see someone who has designed a programming language based
> on *pragmatic* rather than theoretical considerations to invoke it.

That's exactly backwards.  It's better to catch errors at compile time
than at run time.  A program that fails to terminate and fails to
perform I/O is a faulty program.  (A function that performs I/O is
obviously not a candidate for CTFE.)  I'd rather catch the faulty
program by having the compiler lock up at compile time than by having
the compiled program lock up after deployment.  Testing whether the
program terminates at compile time by attempting to execute the program
at compile time is a feature, not a bug.


-- 
Rainer Deyke - rainerd at eldwood.com