19
\$\begingroup\$

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.

\$\endgroup\$
5
  • \$\begingroup\$ 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? \$\endgroup\$
    – Rainbolt
    Feb 12, 2015 at 22:41
  • \$\begingroup\$ @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). \$\endgroup\$
    – Martin Ender
    Feb 12, 2015 at 22:45
  • \$\begingroup\$ 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. \$\endgroup\$
    – Rainbolt
    Feb 12, 2015 at 22:48
  • \$\begingroup\$ @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.) \$\endgroup\$
    – Martin Ender
    Feb 12, 2015 at 22:50
  • \$\begingroup\$ 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? \$\endgroup\$
    – Rainbolt
    Feb 12, 2015 at 22:52

3 Answers 3

Reset to default
30
\$\begingroup\$

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.

\$\endgroup\$
5
  • 2
    \$\begingroup\$ 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. \$\endgroup\$
    – jimmy23013
    Feb 11, 2015 at 16:20
  • 6
    \$\begingroup\$ @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? \$\endgroup\$
    – Sp3000
    Feb 11, 2015 at 21:36
  • \$\begingroup\$ 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. \$\endgroup\$
    – jimmy23013
    Feb 11, 2015 at 21:58
  • \$\begingroup\$ Well I think it can't be fair anyway... Programs in Gammaplex are probably either always valid or always invalid, in any rules. \$\endgroup\$
    – jimmy23013
    Feb 11, 2015 at 22:09
  • \$\begingroup\$ well sometimes it's easier(maybe shorter in code-golf, etc.) to make it terminate, but it makes the output hard to see \$\endgroup\$
    – l4m2
    Mar 31, 2018 at 13:14
21
\$\begingroup\$

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.

\$\endgroup\$
-5
\$\begingroup\$

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.

\$\endgroup\$
2
  • \$\begingroup\$ What's painful about Ctrl-C? \$\endgroup\$
    – feersum
    Feb 18, 2015 at 12:05
  • \$\begingroup\$ @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. \$\endgroup\$
    – jimmy23013
    Feb 18, 2015 at 12:18

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .