22
\$\begingroup\$

Fixed output challenges usually state that the program "must take no input". I usually interpret this as "The standard input is empty", but after thinking about this, there are actually several valid interpretations:

  • The program has to ignore the standard input, that is, it should work regardless of what is given as input.
  • The program has to work only when an empty stream is piped into the standard input.
  • The program has to work without piping anything into it. It may block for user input, but can expect the input to be empty.
  • The program has to work without piping anything into it and it must not block for user input.

There are probably even more interpretations. The last three are worth distinguishing: for instance, my own language Retina was until recently not able to prevent blocking for user input when nothing was piped in - so to really run it without any input one had to do

echo "" | ./Retina -s program.ret

I imagine there are other languages which have this limitation.

So what should the default meaning of "your program must take no input" be?

(There was a related discussion for languages which plainly incapable of executing any code at all if no input is given.)

\$\endgroup\$
6
  • 1
    \$\begingroup\$ In your Retina situation,, does the input have to be empty? Or would the program do the same thing if it got a non-empty input? \$\endgroup\$
    – Reto Koradi
    Oct 11, 2015 at 15:17
  • \$\begingroup\$ @RetoKoradi I don't think I understand your question. Surely that depends on the specific program? My point is just that it was not possible to run Retina at all without any input (if you didn't pipe, it would block for user input from the console). \$\endgroup\$
    – Martin Ender
    Oct 11, 2015 at 19:42
  • \$\begingroup\$ Not sure how I can make it clearer. In the examples you had in mind, would you need interpretation 2 from your list to make the use of Retina feasible, or could you just as well accommodate interpretation 1? \$\endgroup\$
    – Reto Koradi
    Oct 11, 2015 at 20:10
  • 1
    \$\begingroup\$ @RetoKoradi But that depends on the program, not the language. Of course, I can write a program in Retina, which first replaces any input with the empty input so that it would accommodate interpretation 1. If I don't do that, it's likely that it'll only work with interpretation 2, but whether or not that's actually the case will always depend on the actual program, so I don't really understand the question. You could ask the same question for CJam: would echo "" | java -jar cjam.jar program.cjam still work if "" was not an empty string? I don't think the question makes sense in general. \$\endgroup\$
    – Martin Ender
    Oct 11, 2015 at 20:14
  • \$\begingroup\$ I do see a difference between languages there. In CJam, programs that don't need input simply don't read the input, and therefore don't care what it is. From what you're describing, you need to actively ignore input you don't want to use in Retina. That's quite different, and what I wanted to figure out. I think understanding how different languages handle input matters when trying to define rules that work well for all languages. \$\endgroup\$
    – Reto Koradi
    Oct 11, 2015 at 20:54
  • \$\begingroup\$ @RetoKoradi Well consider GolfScript then. For interpretation 1 you'd probably need to start off with ; (but whether that's actually the case, depends on the specific program - something else in the program might already get rid of the input that's already on the stack). As a side note, the program only ever works for a finite input stream (the same would go for Retina). \$\endgroup\$
    – Martin Ender
    Oct 11, 2015 at 21:16

2 Answers 2

Reset to default
38
\$\begingroup\$

Programs may assume that input is empty

I believe that the requirement

The program has to ignore the standard input, that is, it should work regardless of what is given as input.

is too strong. There are (mostly esoteric) languages which automatically read all input there is. These languages would always have to include some code to get rid of that input first, which doesn't really add anything to these submissions (except bytes, of course...).

Hence, programs should generally be allowed to expect that the input is completely empty. Any setup that is necessary for the input to be empty may be expected as well. That is, if a language can only read an empty input from a pipe (as used to be the case with Retina), such an empty pipe can be expected. If a language cannot suppress a user prompt, the solution may expect this prompt to return empty. If a language can only read from a file (for whatever reason), it may expect that file to exist and be empty.

This rule is intended to be as inclusive and fair as possible. I can't see this opening any loopholes, but let me know if you can think of any.

Of course, as usual, any challenge author is free to override this default if their particular challenge becomes more interesting by requiring the code to work for any input (in which case they should clarify whether input can be assumed to be finite).

\$\endgroup\$
11
  • \$\begingroup\$ Question: Let's say your program/function can work without arguments, but taking an empty argument is shorter for the specific language. Can we in that case take an empty argument when none is expected (which we don't use anywhere, we only use it to shorten the byte-count), or would this be disallowed? (I.e. Java lambda function e-> vs ()-> (e = an empty argument we don't use in the program, like "" or null; and () is no arguments at all). \$\endgroup\$
    – Kevin Cruijssen
    Jun 1, 2017 at 12:38
  • 1
    \$\begingroup\$ @KevinCruijssen This post was specifically for programs. I don't know if we have a corresponding post for functions somewhere, but if not it might be worth writing one. \$\endgroup\$
    – Martin Ender
    Jun 1, 2017 at 12:50
  • 1
    \$\begingroup\$ Ok, I've created a new meta-post with this question. \$\endgroup\$
    – Kevin Cruijssen
    Jun 1, 2017 at 14:49
  • \$\begingroup\$ To clarify on this, I'm assuming code like perl -p shouldn't be assumed to allow empty input too? Allowing so would help in many ways when we have to avoid calling print directly as we can rely on the default behaviour to print, or easily call redo as we're within {...}? I've never really considered that valid, but this and Kevin's question has made me think to clarify. \$\endgroup\$
    – Dom Hastings
    Jun 9, 2017 at 7:38
  • \$\begingroup\$ @DomHastings sorry, not quite sure I'm following (because my Perl knowledge is fairly limited). Could you give me some TIO links for a program that you think could abuse this rule (and what it would normally look like)? \$\endgroup\$
    – Martin Ender
    Jun 9, 2017 at 8:11
  • \$\begingroup\$ So it seems that TIO and ideone both ignore output, which is confusing for me, but using the binary on my machine I can run: perl -pe 's//Hello, World!/' <<< '' instead of perl -e 'print"Hello, World!"' for -2 bytes. If used without empty input, it would hang for user input. \$\endgroup\$
    – Dom Hastings
    Jun 9, 2017 at 8:24
  • \$\begingroup\$ Interestingly, putting a null byte in the input does work on TIO. (Without putting a null byte in the output) \$\endgroup\$
    – Dom Hastings
    Jun 9, 2017 at 8:31
  • 1
    \$\begingroup\$ @DomHastings ah I see. Well that's the same problem Retina used to have. It would always expect there to be some input, so if you didn't pipe in an empty input, it would wait for user input. I agree that it's a bit weird to allow this in languages like Perl that can work without any input whatsoever, but I'm not a fan of language-specific rules, so I think it should be fine for all languages to assume that they're being passed an empty input stream. \$\endgroup\$
    – Martin Ender
    Jun 9, 2017 at 8:49
  • \$\begingroup\$ Thanks for the clarification, I'll see if this helps me in any future solves! \$\endgroup\$
    – Dom Hastings
    Jun 9, 2017 at 8:57
  • \$\begingroup\$ In awk when a program has only BEGIN block, it reads no input. A shorter version with only END block behaves the same, except it waits for input (ignoring it). Is it acceptable? \$\endgroup\$
    – mik
    Mar 15, 2021 at 15:52
  • \$\begingroup\$ There are […] languages which automatically read all input there is. These languages would always have to include some code to get rid of that input first, […] Well, tough titties. There is a remarkable amount of accommodations for golfing languages, but standard languages don’t see the same amount of consideration. I’ll therefore repeat the same recommendation others expressed: You can always choose a different language. For some challenges automatically pushing standard input on the stack can be advantageous. For other challenges this can be annoying. \$\endgroup\$
    – Kai Burghardt
    Sep 5 at 18:14
-3
\$\begingroup\$

Programs must not depend on standard input

Take no input means that the program must not depend on standard input.

  • It is not guaranteed that standard input is open for reading, nor that it is attached to a terminal, bound to a regular file, a socket or anything. 
    ./myProgram <&-     # the `<&-` _closes_ standard input
    Your program must run and fulfill the task’s specifications regardless.
  • If it is open for reading, it is not guaranteed that standard input is indeed empty. Your program must not depend on presence or absence of any data in standard input. Standard input may be filled with junk.
  • The state of standard input at the point in time the execution of your submitted code commences must be left untouched until the end of your code. This accounts for the hidden preamble and/or epilog some programming languages/implementations exhibit. E. g. an automatic “flush” (discarding all input) at program termination is harmless.

Rationale

A program can be modeled as a black box or as a mathematical function \$f\$. Such a function \$f\$ takes some inputs and returns some output(s). If there is a “receptacle” for (standard) input, this black box’s behavior could depend on it. Such behavior is banned by the take no input rule. (A dummy receptacle, something that is not “wired”, not connected, is harmless.)

Future directions

A better wording for future challenges might be:

Resources external to the execution environment are unavailable.

The execution environment refers to the black box’s interior. Unavailable indicates, while resources may exist you cannot “touch” them.

\$\endgroup\$

You must log in to answer this question.

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