Can Halting be considered output?

Question

I am currently designing a language that cannot halt unless it all of its memory is cleared, this means for any practical application it has no output whatsoever. However when the program does halt it does output HALTED.

In languages otherwise incapable of traditional output can halting and non-halting be considered outputs for decision-problems that ask for two distinct outputs?

Answer 1

Please no

All languages should follow the same rules, and being incapable of doing something isn't reason for special treatment. And this would be a big rules change for decision problems in every language.

A good number of existing answers could be easily outgolfed by invoking this new option. For example, on Is this number an integer power of -2?, I can cut 3 bytes from the shortest Python answer, 6 bytes from the shortest Haskell answer, and many others, just by removing their bases cases of 0.

Challenges about searching for an object could now be done by enumerating them without limit until one works. For example, the challenge Reachable numbers to check if the input is the totient function of some number can now be done as:

n=input()
i=1
while phi(i)!=n:i+=1

This gets around bounding the maximum possible i, which all existing answers do. This stinks of a hidden rule: an output method that golfers and decision-problem writers wouldn't know is valid unless told so.

The obvious expectation that output methods produce a result. Running code that just keeps going isn't something one would expect to call solving a decision problem. No matter how long you run it, you don't know if it is still yet to halt. Even if you can prove it runs forever, this is not observable: it requires examining the code itself.

Moreover, it defies the meaning of "decision" in computation, that a machine that decides a language must halt by accepting or rejecting, and would let us submit entries to "solve" decision problems that are undecidable, which is ridiculous.

Answer 2

Only if it's halting-ness is proven in the post

It is impossible to prove whether any arbitrary program will halt. That doesn't mean that every program can't be proven.

However, the burden of the proof lies with the poster. If they prove that it will (or won't) halt in the post, then I see no problem.

Answer 3

While halting versus not halting is the classic truthy/falsey output in Turing Machines, you run up into the halting problem when you try to use it practically. It's impossible to say in general whether or not a program in a Turing-complete language will halt. That will cause similar difficulties on PPCG: will the program never halt, or has it not been given enough time?^[1]

A way around this would be to say "if it doesn't halt in N seconds, it doesn't halt", but that opens up more cans of worms about hardware configurations and such.

So, no, halting versus not halting should not be used as a way to indicate truthiness or falsiness.

^{[1]: On a slightly philosophical note, in reality, every program will halt eventually, whether it be due to someone tripping over the power cable, or the heat death of the universe.}