16
\$\begingroup\$

Here's a situation that came up recently in chat, and I realised I'm not sure what our rules are.

A few challenges require code to run without crashing/erroring. As such, a runtime error would make the answer ineligible. For example, here's a requirement from the "add a language to a polyglot" challenge (the original context, but I'm interested in a general answer):

  • Your program must run without erroring out or crashing. Warnings (and other stderr output) are acceptable, but the program must exit normally (e.g. by running off the end of the program, or via a command such as exit that performs normal program termination).

Something that challenges typically don't consider is as to what happens if the compiler crashes. We recently discovered that in Thutu, it's possible to write code that crashes the compiler, but because the compiler writes output as it's running, when it crashes, partially complete output is left in the output file — and it's possible to crash the compiler in such a way that that output is a program that runs without error.

There's something of a philosophical problem here; we normally think in terms of languages as defined by a particular implementation, but in this case, the implementation doesn't really give an opinion, as steps "outside" the compiler itself are relevant. In particular, do we consider the compile technique as compile; run (i.e. attempt to run regardless of what happens in the compile), or compile && run (i.e. run only if the program compiled successfully)?

So my question is, in this sort of situation, does a program that crashes the compiler, but has executable resulting output, count as running without error?

\$\endgroup\$
  • \$\begingroup\$ This is also relevant in Typescript, where the compiler will still generate JS files despite type errors (example). \$\endgroup\$ – Esolanging Fruit Nov 21 '18 at 19:51
13
\$\begingroup\$

In my opinion, yes.

Typically, anything that happens during the compilation stage is ignored. For example, a C/C++ program that produces warnings doesn't make any difference as long the executable runs without errors. You can see this in the text you quoted: (emphasis added)

Your program must run without erroring out or crashing. Warnings (and other stderr output) are acceptable, but the program must exit normally (e.g. by running off the end of the program, or via a command such as exit that performs normal program termination).

This would seem to imply that anything happening during the compilation stage is irrelevant to the final submission.

I would consider the compiler technique to be compile; run. If your compiler step crashes your computer, burns your house down, or causes gremlins to fly out of your keyboard, this doesn't matter since the compiler still was able to create a valid executable.

\$\endgroup\$
  • 6
    \$\begingroup\$ I've always wanted an esolang that does something strange like order a pizza, or cause gremlins to fly out of your keyboard, or perhaps just send debug output to an actual printer. \$\endgroup\$ – Rohan Jhunjhunwala May 20 '17 at 1:30
  • \$\begingroup\$ You don't need an esolang for that, @rohan, just a sadistic bent while writing a C compiler. Nasal demons might prove difficult to implement, but formatting your hard disk or ordering a pizza would be downright trivial. \$\endgroup\$ – Cody Gray May 30 '17 at 8:33
-2
\$\begingroup\$

If the compiler crashes, fix it

If the compiler crashes, you must either use a different compiler or provide a patch for the compiler you are using, such that this is no compiler crash.

\$\endgroup\$
  • 2
    \$\begingroup\$ In the example I'm thinking of, the compiler intentionally crashes on any syntax error (this is fairly common with esolang compilers, which use asserts or the like rather than proper error handling). In any case, using a different compiler would in most cases violate the long-standing PPCG rule that you can only use compilers that predate the challenge; you're contradicting this post, specifically. \$\endgroup\$ – user62131 May 31 '17 at 21:56

You must log in to answer this question.