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

[Jim Balter]

"Don" <nospam at nospam.com> wrote in message 
news:i2ice7$2i7r$1 at digitalmars.com...
> Jim Balter wrote:
>> "Walter Bright" <newshound2 at digitalmars.com> wrote in message 
>> news:i2flvi$4io$1 at 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.