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 - [email protected]
