+1
Nathan
Domenic Denicola wrote:
> A well-known problem with loops, as implemented in various programming
> languages, is that infinite loops are silenced by default. Consider the
> following program, which simply adds some numbers in a loop:
>
> ```js
> var sum = 0;
> while (Math.random() < config.loopLimt) { // Note the misspelling!
> sum += Math.random();
> }
> ```
>
> On line two, the property "loopLimit" is misspelled, which should cause the
> program to report an infinite loop as the condition will never be true. Under
> the current programming language paradigm, however, the error will be
> silenced and the program will loop happily forever.
>
> Various solutions have been proposed for dealing with this problem, such as:
>
> - Extending debugging tools to allow some visibility into the code currently
> running in your program, through a specialized tab or view.
>
> - Using CPU consumption to determine when a loop has locked up the program,
> and thus probably consistutes a program error.
>
> - Adding a `safeWhile` construct to the language which ensures you cannot
> loop more than 64K times.
>
> While each of these approaches provides a partial solution to the problem,
> they are ultimately inadequate because they do not address the underlying
> cause.
>
> The root cause of this issue is that, as currently specified, **the problem
> of deciding whether a particular `while` loop terminates is Turing
> undecidable**.
>
> This is *not* a desirable property for a looping mechanism to have, and it is
> not a design choice that can be reversed at a later date.
>
> In order to make loop termination decidable, it is sufficient to require that
> the loop condition must be become true *within a well-defined window*. One
> such window would be the current second.
>
> The designers of regular expressions have made a similar decision with their
> string matching API. A quick search on StackOverflow relating to loops and
> "infinite" loops in regular expressions yielded no results. This cursory
> evidence suggests that requiring looping constructs to be finite is not a
> significant problem for regular expression users.
>
> In my view, it would be a mistake to standardize the undecidable looping
> model of the current `while` loop design.
>
> ---
>
> Which is all to say, being unable to Turing-decide how a programming
> construct will work is not a particularly noteworthy disqualifier, and indeed
> opens up extremely powerful features in most cases. I believe the same is
> true of the current promise design.
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
