It looks like we have a consensus that we want certain defaults for the format which answers are expected in for . On that poll, the question arose twice, which input/output formats should be allowed for programs and functions.

So here is another poll. This one works different though. All the input/output methods are independent of each other, so there will be one answer per method. Upvote all you think are reasonable for the default. Downvote those which you think shouldn't be allowed unless the OP explicitly permits them.

To keep this remotely manageable, I have not posted individual answers for all possible inputs for functions. So there are only four: functions can take input/output via their arguments and return values. Or functions can use any method full programs can. I don't think there is any point in (say) allowing programs to take input from STDIN (only) and to allow functions to take input from ARGV (only) or something like that. If you disagree, please leave a comment.

If I've overlooked an I/O method, feel free to add your own answer.

At the end of the week, I will amend the tag wiki, allowing all methods by default which have 5 net votes and at least twice as many upvotes as downvotes. I will try to keep an eye on this in the future, to amend the defaults if the polls change.

Note: Some votes have been reverted because they were detected as serial voting. If you vote on multiple answers, please leave some time between votes.

Update

The current results of the polls are now part of the tag wiki. Please notify me, if results change significantly and the wiki should be amended.

share

36 Answers 36

Functions may output via their return value(s)

share
1  
This has my upvote. – Martin Büttner Nov 2 '14 at 23:15
10  
@hosch250 Wait, are there languages that have functions without return values? o.O – Martin Büttner Nov 3 '14 at 0:17

Programs may take input via STDIN

share
1  
This has my upvote. – Martin Büttner Nov 2 '14 at 23:09
4  
Should I downvote this? – Bojidar Marinov Nov 16 '15 at 20:24

Programs may output to STDOUT

share
1  
This has my upvote. – Martin Büttner Nov 2 '14 at 23:12
2  
did you have to do this to every single one you voted up? – TheDoctor Nov 4 '14 at 23:25
5  
@TheDoctor I can't actually vote, because I posted the answers myself, so those comments are my votes. – Martin Büttner Nov 4 '14 at 23:28
1  
Ah that makes sense – TheDoctor Nov 4 '14 at 23:38

Functions may take input via function arguments

share
1  
This has my upvote. – Martin Büttner Nov 2 '14 at 23:12

Programs may take input via GUI prompts

(This is for languages, for which this is the closest alternative to STDIN, like JavaScript's prompt(), Mathematica's Input[] or InputString[] and Matlab's input().)

share
1  
This has my upvote. – Martin Büttner Nov 3 '14 at 0:11
1  
What about for other languages? – Ypnypn Nov 4 '14 at 0:32

Programs may take input via command-line arguments

share
1  
This has my upvote. – Martin Büttner Nov 2 '14 at 23:11

Programs may output by displaying it on screen.

This makes it possible to use languages like Vim script that can't print output directly to stdout.

Example from this challenge:

$ echo "This is a test line!" | vim - -c 'nm Q vEUWvEuWQ|norm Q'

Will display:

THIS is A test LINE!
~
~
~
~
~

Within a Vim session.

I think that this way of displaying the result should be valid. I am sure that there are other domain specific languages like Vim script that lacks full I/O support and could use another way to display the result.

share

Functions may output via the same methods as full programs

(This depends on how the poll goes, but could be any subset of STDOUT, STDERR and file.)

share
1  
@JanDvorak One simple golf use is that print is shorter than return in Python. – xnor Nov 3 '14 at 8:57
1  
Eugh. Not a fan of that optimisation. What it could be useful for is printing in a loop rather than collecting results in an array. Still not a fan of allowing that. – Jan Dvorak Nov 3 '14 at 9:02
8  
@xnor Why not, full programs are allowed to do that, too, right? – Martin Büttner Nov 3 '14 at 11:22

Functions may take multiple arguments via currying

For some functional programming languages like Haskell this is actually necessary, because only single-argument functions exist and functions with multiple arguments are (somewhat transparently) implemented as curried functions. (The alternative would be to take a list or tuple of the values, but that is not how one would naturally write a two-argument function in Haskell.)

As per this consensus the same should also be allowable for languages where multi-argument functions do exist. As an example from JavaScript, instead of defining

f=(a,b)=>...

and calling it like f(a,b) one could then also define

f=a=>b=>...

and call it like f(a)(b).

share
1  
@ChristianIrwan True (if that is even allowed) - I clarified that part a bit. – Martin Büttner Feb 19 at 10:53

Programs may output using their exit code...

... if and only if the challenge requires an integer as output, obviously.

Exit codes are basically a return value for programs. If functions can output using their return values, it makes sense that programs should be able to do the same.

Examples:

share

Functions may take input via the same methods as full programs

(This depends on how the poll goes, but could be any subset of STDIN, ARGV and file.)

share
11  
@JanDvorak I don't see the relevance of good coding practices for code golf. And some languages don't even have functions and they aren't necessarily at a disadvantage by allowing functions. The idea of being more liberal in the options for I/O is so that each language can pick what's really shortest. – Martin Büttner Nov 3 '14 at 11:10
1  
The only time that I would object to a function taking input in the same way as a program is if the question was phrased "Write a function that takes the following arguments". This poll applies to questions that are not in such a specific format, so I see no reason to exclude functions that read from stdin. – trichoplax Nov 4 '14 at 13:16

Functions may output by modifying their arguments or writing to out arguments

share
4  
@ThomasKwa Yes, provided the changed value will then be accessible in the context that called the function. – Martin Büttner Jun 10 '15 at 21:18

Programs may combine two or more input methods

For example, if the inputs are a string and an int, a function that takes a string as an argument and an int from STDIN would be valid.

The input format must still be consistent for a given program.

share

Programs may output to a file

share
1  
This has my downvote. – Martin Büttner Nov 7 '14 at 9:45
5  
Why are people against this? – xnor Nov 8 '14 at 5:48
1  
@xnor is /dev/null considered a valid output file? I might as well submit a blank program and claim it outputs the correct answer to /dev/null. – Patrick Roberts Feb 15 at 21:55

The contents of the tape post-execution may be used as a Turing machine's output

share
2  
This has my upvote. – SuperJedi224 Sep 22 '15 at 20:54

Where applicable, Turing machines supporting multiple halt states may also output via their halt state

This is equivalent to programs outputting via their exit code.

share
1  
This has my upvote. – SuperJedi224 Sep 22 '15 at 20:54

Input for Turing machines may be written to the tape pre-execution

The read-write head should start on the leftmost cell of the portion of the tape containing the input.

share
1  
This has my upvote. – SuperJedi224 Sep 22 '15 at 20:53
3  
I think this should only be allowed if that's the only method of input. – mbomb007 Oct 8 '15 at 20:39
1  
For standard turing machines, it is. – SuperJedi224 Oct 8 '15 at 20:59

SQLs may take input from a named table

which is probably not good enough. But I don't know a better way.

share

Input for stack-based language's functions may be pushed to the stack before calling

Stack-based languages may assume that the input for their function is automatically pushed to the stack.

share
1  
+1, this is the de facto standard for CJam and GolfScript (and probably some other stack-based languages). You might want to make a corresponding answer for output. – Martin Büttner Feb 19 at 13:29
1  
I think the emphasis here needs to be on "function", as opposed to snippet. There's a very fine line between the two... – Sp3000 Feb 19 at 13:34

Programs may take input from a file

share
5  
... only if makes sense for the challenge, and even then you should input a file name first... I'd say – Jan Dvorak Nov 3 '14 at 6:32
2  
@JanDvorak That's a "no", because that makes the file name itself the input (which you would take from STDIN or ARGV). – Martin Büttner Nov 3 '14 at 11:07

Functions in stack-based languages can leave the output on the stack

Mostly for completeness sake. This is the de-facto standard for CJam and GolfScript and probably other stack-based languages.

share

Regexes may output via the list of matched strings (the captured group 0)

share

CGI scripts may take input via GET/POST parameters

A CGI script required to take, e.g., three inputs can be expected to be called as the GET request

GET script.cgi?<A>=<1st input>&<B>=<2nd input>&<C>=<3rd input> HTTP/1.1

(where A, B and C are keys of the poster's choice) of the equivalent POST request.

share
1  
@jimmy23013 PHP4.1: <?eval($c); (assuming short_tags and register_globals, the code can be anywhere, even in a cookie (if below 4kb)). Or even <?eval(fgets(STDIN)). Or, for Javascript, eval(prompt()). Or eval "$s" for bash. Other languages have the same problem. Any language that allows evaluation of a string containing code has the same problem – Ismael Miguel Nov 27 '15 at 20:19

Assembly programs may take input from registers

If there are no I/O devices available, an answer might consist of a subroutine that reads its input values from the machine registers.

share

Assembly programs may write output to registers

If there are no I/O devices available, an answer might consist of a subroutine that leaves its computed output values in the machine registers upon returning.

share

Assembly programs may read input from some specified memory location

If there are no I/O devices available, an answer might consist of a subroutine that reads its input values from some specified memory location (e.g. read a zero-terminated string starting at $0000).

share

Assembly programs may write output to some specified memory location

If there are no I/O devices available, an answer might consist of a subroutine that writes its output values to some specified memory location (e.g. write a machine word to $0000).

share

Regexes may output a number via the number of matches

Or truthy / falsey as whether they match.

share
6  
Plain regex submissions are still not generally accepted as valid so I'm not sure it's worth adding defaults for this very specific case that a lot of people don't accept at all. – Martin Büttner May 30 '15 at 10:27

Regexes may output via any captured groups

The users can specify which captured group(s) contain the output, not necessarily group 0.

share

Programs may take input as the value of the last expression

Using something like TI-84 BASIC's Ans, which is a variable that stores the value of the last expression. This the shortest way for TI-BASIC to take input, but its validity was recently questioned. To be clear, this is how the process works with Ans:

  • Within a program, type the input (number, list, string, etc.), followed by a newline to separate statements, followed by the program name, then press Enter. For example,

    1337
    prgmFACTOR
    
  • Outside a program, type the input, press Enter, then type the program name and press Enter.

share
3  
I think by definition that submission would not be a full program but a snippet that requires some sort of REPL environment which are disallowed by default. – Martin Büttner Feb 25 at 22:53
2  
I think that TI-BASIC is a special case, it being fundamentally different from other languages, and only being callable from what can be considered a REPL; so what then is to differ a full program from a snippet? – Cᴏɴᴏʀ O'Bʀɪᴇɴ Feb 29 at 17:06
2  
@CᴏɴᴏʀO'Bʀɪᴇɴ I disagree, you can write full programs in the REPL but you can also write them in separate "files" that can be executed. They even support arguments when the program is called, but can also read from stdin or via prompt. – flawr Mar 5 at 12:55

You must log in to answer this question.

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