# Do programs have to terminate?

This is related to Sp3000's question earlier, but probably a separate issue:

Are programs required to terminate, provided they print the desired output before entering an endless loop and can be proven to never print anything else in the future?

As a fake example, consider the following "Hello, World!" submission in JavaScript:

console.log("Hello, World!");
while(true);


This prints the desired output, and will never print anything else, but it doesn't terminate.

REPL submission snippets and function snippets should also be considered in the answers.

• Are you only asking about programs that truly never terminate or are you also including programs that terminate after an arbitrarily large amount of time? Feb 12 '15 at 22:41
• @Rainbolt Only the former. I'm asking about programs that actually won't terminate at all (barring recursion limits, out-of-memory errors and your power cutting out). Feb 12 '15 at 22:45
• I would consider adding the other category. I don't see how a program that takes five years to run is more legitimate than a program that runs forever. Feb 12 '15 at 22:48
• @Rainbolt While it could probably use some official ruling, I believe that it's a fundamentally different question whether you consider a non-terminating program a valid program or whether you're talking about a program that is just really really slow. (It's also a much more difficult question, because if you do want to disallow it you need to make some sort of cut-off by one criterion or another, whereas the question of terminating or not is a simple yes/no.) Feb 12 '15 at 22:50
• Ok. What if you can't prove which category an answer belongs to (really slow or non-terminating)? Do you then see the need to treat them the same? Feb 12 '15 at 22:52

# Submissions should always terminate by default

Personally, I think this is just the neater option, simple as that. If we allow non-terminating submissions, then it'll just feel like a "hidden rule" to new users.

• There is a problem for languages which open new windows to display messages, which are supposed to not terminate before the user click a button. Feb 11 '15 at 16:20
• @user23013 I'm not sure how that would be a problem. Can't we treat those messages as though they go to STDOUT, as if the user is diligent enough to go click through all the boxes? Feb 11 '15 at 21:36
• For languages like Gammaplex, the way ending a program and keep that box open is just an infinite loop... Maybe we can say the user must be able to close the program in the program itself, instead of using something like Ctrl-C. Feb 11 '15 at 21:58
• Well I think it can't be fair anyway... Programs in Gammaplex are probably either always valid or always invalid, in any rules. Feb 11 '15 at 22:09
• well sometimes it's easier(maybe shorter in code-golf, etc.) to make it terminate, but it makes the output hard to see
– l4m2
Mar 31 '18 at 13:14

I think this also needs separate rules for programs and other submissions.

## Full Programs

I believe this is fine, provided the answer comes with a justification for why the submission will only print the required output, nothing more, nothing less.

## REPL Snippets and Functions

In these cases, I think this should not be allowed. The purpose of REPL snippets and functions is that they can be reused without restarting the REPL/program. An endless loop would defeat that purpose. If you want your submission not to terminate, answer with a full program.

As usual, any challenge author may override any of these defaults if they so wish.

# The user must be able to terminate the program in the program itself

Not by sending signals like using Ctrl+C, or killing the process.

I think we probably don't really care, but want to reduce some pain for people testing their submissions.

• What's painful about Ctrl-C? Feb 18 '15 at 12:05
• @feersum I'm not sure... Maybe we can post another answer allowing Ctrl-C. But this answer isn't getting upvotes anyway. I think that wouldn't change much. Feb 18 '15 at 12:18