Current consensus seems to be that programs must terminate by default. This makes sense in general. However, does this bar use of languages which are not designed with a halt state (other than manually stopping the program)?
For example, take something like ByteBeat, which I believe is a family of languages which evaluate a single expression at continually, infinitely increasing values of a variable
t (representing time) and outputting as audio. Could we use this in an answer which did not specify anything about infinite output? Could a ByteBeat program infinitely loop outputting twinkle twinkle little star? Or maybe just play it once, and then remain silent for eternity onward?
There are also automata like rule 110 which are Turing-Complete but have no way to halt. It's easy to argue, however, that these are not languages, and that a language implementation of such a thing would have a well defined halt state / output.
Alternatively, in this language (and likely others) you are able to guarantee that after a certain point, nothing more will be output. In ByteBeat, this would be done by having an expression which always error after a certain fixed value, like this:
(t>100?1/0:1). Important to note that this would not halt with error, it would simply not evaluate to any outputtable sound.
Also worth note: Languages without I/O capabilities such as /// are allowed to hardcode their input, and see the other various rules in the linked question for other examples of exceptions made for languages which lack certain features.
So, in general, programs must halt unless specified in a challenge, but do we have any exceptions for languages without halt states? Does it make a difference if their output is (fairly) well defined, and/or there is a way to guarantee finite output even in theoretically infinite time?