News for hackers. Stuff that matters.
Re:Power of Small Optimizations by towawy on Saturday February 10, 2024 @08:35AM (#39326020)
You can also construct programs in Turing complete languages to always halt (e.g. by bounding the number of iterations of all loops, usually with the tradeoff of limited input size).
Re:Power of Small Optimizations by eru on Saturday February 10, 2024 @09:48AM (#39326497)
Yes, you can program in a subset of your language that is not Turing complete.
Re:Power of Small Optimizations by The_Colonel on Saturday February 10, 2024 @10:07AM (#39326647)
You'd also need to forbid (even indirect) recursion, i. e. one function cannot appear in a callstack twice.
Re:Power of Small Optimizations by trealira on Saturday February 10, 2024 @10:27AM (#39326803)
Isn't that overly restrictive? Some programs are guaranteed to terminate even with mutual recursion.

For example, these (obviously inefficient) functions always terminate for all values of x, since both terminate given an input of 0, and 0 is the minimum possible input to these functions.

  bool even(unsigned int x)
  {
    return (n == 0) ? true : odd(n - 1);
  }

  bool odd(unsigned int x)
  {
    return (n == 0) ? false : even(n - 1);
  }
Re:Power of Small Optimizations by The_Colonel on Sunday February 11, 2024 @02:08PM (#39337589)
The point of these restrictions is that you can formally verify that a given program will terminate in a way which can be checked by e.g. a compiler or some other kind of checker.

While statically verifying your snippet is possible, it is also significantly more difficult to do than enforcing rules like "all loops must have an upper limit". I also think that you'd need dependent types to make this approach viable. Your simple example is IMHO rather an exception, just having "unsigned int" parameters / return types would mostly not suffice to statically verify that a recursive method will finish or not. (plus things like global state etc.)

Re:Power of Small Optimizations by eru on Monday February 12, 2024 @10:00AM (#39345479)
A language with your suggested restriction (and a few more) might be possible.

But it's not the only way to get a total language (that always halts), contrary to what your original comment claims.

Re:Power of Small Optimizations by zmgsabst on Saturday February 10, 2024 @10:22AM (#39326757)
I think you can allow finite recursions, eg, a maximum stack depth.
Re:Power of Small Optimizations by The_Colonel on Sunday February 11, 2024 @02:18PM (#39337698)
But then reaching it will mean a crash. I could use a similar approach to say that any program will terminate if I set a fixed time (instruction count) limit.
Re:Power of Small Optimizations by zmgsabst on Monday February 12, 2024 @08:50AM (#39344694)
Yes — that’s correct.

Programs with a fixed amount of execution time always terminate. That’s why we add timeouts to executions, because they’re a solution to the halting problem, which guarantees execution flow of our machines always returns at some point.

Re:Power of Small Optimizations by eru on Monday February 12, 2024 @09:59AM (#39345467)
Agda doesn't need that restriction, as far as I know. And neither does Dhall. See https://dhall-lang.org/

Neither language is Turing complete.