current community

your communities

more stack exchange communities

company blog
Stack Exchange Inbox Reputation and Badges
tour help
up vote 35 down vote favorite
6

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.

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
    
Related (Can numeric input/output be in the form of byte values) – mbomb007 Dec 13 '16 at 16:10

41 Answers 41

1 2
up vote 73 down vote

Functions may output via their return value(s)

share
1  
This has my upvote. – Martin Ender♦ Nov 2 '14 at 23:15
    
How many languages support this? I support outputting to STDOUT. – Dain II Ironfoot Nov 3 '14 at 0:16
15  
@hosch250 Wait, are there languages that have functions without return values? o.O – Martin Ender♦ Nov 3 '14 at 0:17
    
Oh, that is not considered outputting the last I heard - that is returning a value. If the question asks for a function, this is correct. If the question asks for a program, I support outputting to STDOUT or a file. – Dain II Ironfoot Nov 3 '14 at 0:19
    
@hosch250 This particular answer only concerns functions. Whether functions and/or programs are allowed is another question (see the linked meta question, but of course it's ultimately up to the challenge author). But this answers says that if functions are allowed, then they should be allowed to use their return value for the result - as are all other answers here that start with the word Functions. – Martin Ender♦ Nov 3 '14 at 0:21
    
Oh, sorry. I definitely will vote on this then. – Dain II Ironfoot Nov 3 '14 at 0:22
up vote 64 down vote

Programs may output to STDOUT

share
1  
This has my upvote. – Martin Ender♦ Nov 2 '14 at 23:12
3  
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 Ender♦ Nov 4 '14 at 23:28
1  
Ah that makes sense – TheDoctor Nov 4 '14 at 23:38
up vote 63 down vote

Programs may take input via STDIN

share
1  
This has my upvote. – Martin Ender♦ Nov 2 '14 at 23:09
up vote 59 down vote

Functions may take input via function arguments

share
1  
This has my upvote. – Martin Ender♦ Nov 2 '14 at 23:12
    
I use this in a lot of my questions, so definitely. – Joe Z. Nov 16 '14 at 22:43
up vote 53 down vote

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 Ender♦ Nov 3 '14 at 0:11
1  
What about for other languages? – Ypnypn Nov 4 '14 at 0:32
    
@Ypnypn I'm not aware of a language which can read from STDIN, but where producing a graphical prompt is shorter than that. But in that case, I'd say either is fine. – Martin Ender♦ Nov 4 '14 at 9:22
1  
@MartinBüttner Matlabs input('') usually just reads from the command line, perhaps you mean inputdlg('')? – flawr Sep 11 '15 at 16:29
    
Anyway, Mma's Input and InputString both take the next line of input when run in a script. – LegionMammal978 Nov 8 '15 at 12:35
    
@MartinEnder wscript. – wizzwizz4 Jul 21 '16 at 15:47
up vote 44 down vote

Programs may take input via command-line arguments

share
1  
This has my upvote. – Martin Ender♦ Nov 2 '14 at 23:11
up vote 43 down vote

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
    
Incidentally, vim's output is standard output, but if you processed standard output, there is extra garbage there. – Joshua Jan 25 '16 at 20:04
    
It's not even just domain specific languages. I'd say QBasic falls in this category: it doesn't have any concept of an output (or input) stream, but rather writes characters to a "window." – DLosc Sep 3 '16 at 3:51
up vote 39 down vote

Programs may output using their exit code...

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
    
Hmm…should this perhaps be "if and only if the challenge requires as output an integer whose value is guaranteed to be between 0 and 255, inclusive"? For example, if the challenge is "output the number of arguments passed to the program," then int main(int argc, char **argv) { return argc; } should not be a valid solution (IMO), because the exit code is masked by 0xFF. (Perhaps this is implicit in the rule as a part of correctness? Just want to be clear.) – wchargin Dec 18 '16 at 5:05
    
@wchargin That seems like a limitation of whatever you are using to run your program. I can write a PowerShell script like exit 1000000, and execute it in PowerShell ISE. This gives me no problems. – Rainbolt Dec 19 '16 at 19:14
    
Interesting—I didn't know that. As far as I know, this is true on all *nix OSes (including Mac), but I'd be happy to be corrected! – wchargin Dec 19 '16 at 19:21
    
is there a reason to limit this to integers? i mean if there's an environment where a program can return something other than an integer why not allow that too? – Jasen Dec 22 '16 at 10:21
    
@Jasen I don't see a reason to limit it to integers. – Rainbolt Dec 22 '16 at 14:04
up vote 38 down vote

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
up vote 34 down vote

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  
This has my upvote. – Martin Ender♦ Nov 3 '14 at 1:56
    
This violates the single-responsibility principle, the separation of concerns principle, and I don't think it's really useful in code golf. Moreover, functional programming languages won't let you do that at all, and I want some more love for Haskell. – Jan Dvorak Nov 3 '14 at 6:42
1  
@JanDvorak One simple golf use is that print is shorter than return in Python. – xnor Nov 3 '14 at 8:57
3  
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
    
@JanDvorak Yeesh, I did not consider that one could print repeatedly to "output" a list. I think that should not be allowed even if this vote passes because the output is not the list that is asked for. – xnor Nov 3 '14 at 9:06
9  
@xnor Why not, full programs are allowed to do that, too, right? – Martin Ender♦ Nov 3 '14 at 11:22
    
@MartinBüttner Hmm, you're right, what a program really "outputs" is the string representation of the result, so this rule should mean functions can too for consistency. But this is another awkward consequence that makes me disfavor this rule. – xnor Nov 4 '14 at 2:15
up vote 29 down vote

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
1  
This has my upvote. – Martin Ender♦ Nov 3 '14 at 1:56
    
This violates the single-responsibility principle, the separation of concerns principle, and I don't think it's really useful in code golf. Moreover, functional programming languages won't let you do that at all, and I want some more love for Haskell. – Jan Dvorak Nov 3 '14 at 6:43
13  
@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 Ender♦ 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
    
@MartinBüttner noted. I still don't like this option, but feel free to override my preferences. The vote split is very close to the threshold ATM. – Jan Dvorak Nov 7 '14 at 9:47
up vote 29 down vote

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

share
1  
This has my upvote. – Martin Ender♦ Mar 25 '15 at 10:51
2  
Does this mean that in languages that allow it, the seven characters for return can simply be replaced with an assignment? – lirtosiast Jun 10 '15 at 21:05
7  
@ThomasKwa Yes, provided the changed value will then be accessible in the context that called the function. – Martin Ender♦ Jun 10 '15 at 21:18
    
so you mean this is only legal in languages that have out arguments, pass by reference, or some similar semantic? for instance not in shell... – Jasen Dec 22 '16 at 10:27
    
@Jasen I don't know about shell, but yes to your question. – Martin Ender♦ Dec 22 '16 at 10:31
up vote 26 down vote

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
up vote 24 down vote

Programs may output to a file

share
2  
This has my downvote. – Martin Ender♦ Nov 7 '14 at 9:45
8  
Why are people against this? – xnor Nov 8 '14 at 5:48
3  
@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 '16 at 21:55
5  
@PatrickRoberts No, /dev/null is not a valid output file, for the exact reason that the output cannot be examined later. "Output to a file" means that you can see the program's output by viewing a particular file. – DLosc Sep 3 '16 at 4:05
1  
using strace (or chroot, or mv!) you can see what was written to /dev/null – Jasen Dec 22 '16 at 10:30
up vote 24 down vote

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
up vote 23 down vote

SQLs may take input from a named table

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

share
up vote 21 down vote

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
2  
This has my upvote. – SuperJedi224 Sep 22 '15 at 20:54
    
Turing Machines as I've seen them defined leave output on their tape and have a single halt state. Is there some precedent for what you are suggesting? – xnor Sep 24 '15 at 16:51
    
@xnor: That is usually the case, but I have seen dialects of turing machine code that do support multiple halt states. (For example, in the morphett.info dialect that I usually use, halt is the basic halt state, but any state of the form halt-<any string> is also treated as a halt state.) – SuperJedi224 Sep 24 '15 at 19:09
up vote 21 down vote

For stack-based languages, function's input 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 Ender♦ Feb 19 '16 at 13:29
3  
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 '16 at 13:34
    
Are there any stack based langauges that let you define functions? As far as I am aware most of them do not and do only let you write full programs with IO via STDIO. (in my opinion functions should satisfy (perhaps among other criterions): pieces of code that can be reused in the same program, without typing them out again) – flawr Jul 10 '16 at 16:27
    
@flawr Vitsy has functions, in some aspects. There are a few stack-based languages that have scope, but I can't name them immediately. – VoteToClose Jul 11 '16 at 4:12
1  
@flawr for completion sake: lots (most?) of non-esoteric stack-based languages let you define functions. Factor, Forth, Postscript, Joy, Cat, and many others all have functions (both named and anonymous). dc (the RPN calculator) has registers that can work like functions. – fede s. Sep 14 '16 at 17:35
up vote 18 down vote

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
4  
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
    
@SuperJedi224 As far as I know, you can't vote for your own post. – TheBitByte Dec 28 '16 at 1:32
up vote 17 down vote

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
    
This is also how Forth works. – mbomb007 Aug 3 '16 at 15:18
up vote 13 down vote

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
    
There's potential for abuse. What if someone creates a machine with a million different special-purpose registers? – lirtosiast Mar 15 '16 at 17:10
3  
@lirtosiast Good for code colf then. I don't see how that's different from golfing languages with prefilled vars – cat Jul 6 '16 at 0:31
    
@lirtosiast I believe the programming language used has to be defined before the challenge starts. – YoYoYonnY Dec 31 '16 at 21:19
    
If you golf with x86-64, the standard calling conventions already pass args in registers. So you can just write a normal function that's callable from compiler-generated code. – Peter Cordes Jan 1 at 7:06
up vote 13 down vote

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
1  
This would be natural for various 8-bit micros. – zwol Mar 1 '16 at 4:50
1  
and for ms-dos where the command-line is at 80h – Jasen Dec 22 '16 at 10:35
up vote 13 down vote

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
up vote 11 down vote

Programs may output to STDERR

share
5  
Can anyone give a comment as to why not to? For example, print("Hello, world!") in lua prints to STDERR. – YoYoYonnY Jan 31 '16 at 0:40
    
Forbidding output to STDERR seems incompatible with allowing output to the screen. – Dennis♦ May 2 '16 at 18:47
    
This should go as standar... Ah. I see. – wizzwizz4 Jul 21 '16 at 16:00
    
The only problem I see with this is vagueness between what is written to STDERR by the "language" and what is written by the "program." If a distinction between those is not made, this would permit error quines and answers like this, which is questionably valid. – Challenger5 Dec 29 '16 at 18:29
up vote 11 down vote

Programs may take input from a file

share
8  
... 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 Ender♦ Nov 3 '14 at 11:07
2  
This has my downvote. – Martin Ender♦ Nov 7 '14 at 9:45
up vote 11 down vote

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

share
1  
We now have Retina for regex so this can – CalculatorFeline Apr 2 '16 at 16:13
up vote 11 down vote

In languages without any method of input (e.g. ///) programs may get input through an insertion into the source code

share
    
@DLosc What about code in /// that requires changing at the end? E.g. a simple program that adds a full stop to the end of a string if there isn't already a full stop there /.;/;//x///;/.x;/(input goes here); where x is a special character (maybe a newline) that is guaranteed not to be in the input. – boboquack Nov 20 '16 at 9:34
    
Okay, I guess there isn't any other reasonable way to do that. Comment retracted. – DLosc Nov 20 '16 at 9:45
up vote 10 down vote

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
    
Also, PHP<5.4.0 (exclude) has the directive register_globals (enabled by default up to PHP4.1), which allows you to use POST, GET, COOKIE, SESSION and what-not. It creates the variables with the names of the keys (E.g.: a.php?a=1 would create $_GET[a] (version-dependent) and the variable $a with value 1). This was removed due to security reasons, but was a standard feature that was (fortunally) removed. – Ismael Miguel Nov 27 '15 at 17:52
    
Also, would parse_str($_SERVER[QUERY_STRING]) be a valid input method? It does exactly the same as register_globals, but reads input parameters from a superglobal and parse them into variables. This is explained in the documentation: php.net/manual/en/function.parse-str.php – Ismael Miguel Nov 27 '15 at 18:01
    
This proposed a specific input method. What language features you use to access that input is up to you. – Dennis♦ Nov 27 '15 at 18:20
    
Then using $_GET (superglobal with all GET parameters, in PHP) fits the "What language features you use to access that input is up to you", right? – Ismael Miguel Nov 27 '15 at 18:25
    
Yes, it does, assuming a GET request becomes an accepted input input. – Dennis♦ Nov 27 '15 at 18:37
    
Then there is the program <?php eval(key($_GET));. (SQL table input may have similar problems.) – jimmy23013 Nov 27 '15 at 18:51
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
    
@Dennis Would eval(`return {${location.hash}}`), assuming your URL is http://example.com/#a:"value",other:"value", fit in this definition? – Ismael Miguel Nov 27 '15 at 20:32
    
@IsmaelMiguel As written, no. Those are neither GET nor POST parameters. – Dennis♦ Nov 27 '15 at 20:34
    
@Dennis What about eval(location.search.replace(/^\?/,''))? It would create every single variable you would need, right away (if the input is numeric and not an array). The location.search will contain all the GET parameters, optionally starting with an ?. – Ismael Miguel Nov 27 '15 at 20:38
    
This can also be done with php -r '<code>' <A>=<input1> <B>=<input2> (or php-cli, depending on your distribution/installation), which alleviates the need for a web server (a much better option IMO). In this case, scoring is much easier: the -r flag would cost 2 bytes, but the ability to drop the leading <? in the code balances it out. Each GET parameter would cost 1 byte (for the =) plus the length of the parameter name. – Mego Nov 28 '15 at 6:11
    
@Mego The -r is free. Read: meta.codegolf.stackexchange.com/q/2424/14732 – Ismael Miguel Nov 28 '15 at 22:44
    
@IsmaelMiguel Fair enough. The rest of my comment still stands. – Mego Nov 28 '15 at 23:42
    
@Mego It's still under discussion. – Ismael Miguel Nov 29 '15 at 1:09
    
@IsmaelMiguel Hence why I offered my opinion – Mego Nov 29 '15 at 1:58
up vote 10 down vote

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
    
Most calling conventions return integer values in a register, so this is eminently sensible for code fragments and functions. – Peter Cordes Jan 1 at 7:12
up vote 9 down vote

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.

Edit: I came across a way of using Ans that is similar to command-line arguments, which are allowed: All as one expression, type the input, followed by a colon, followed by pgrmWHATEVERTHENAMEIS. For example, 1337:pgrmFACTOR.

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 Ender♦ Feb 25 '16 at 22:53
4  
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? – Conor O'Brien Feb 29 '16 at 17:06
4  
@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 '16 at 12:55
    
@flawr On the 84+ series they can't take arguments, and there's no STDIN, only a prompt. – lirtosiast Mar 15 '16 at 16:48
2  
@lirtosiast According to the official TI 84+ guidebook both commands Input and Prompt are available. Both let the program fetch user input. Both behave alot like e.g. input() in Python or MATLAB. – flawr Mar 15 '16 at 17:59
    
@flawr I agree about their similarity; what I meant is that they display a ? that prompts the user to type something. – lirtosiast Mar 15 '16 at 18:00
1  
@lirtosiast Is that an issue? I think many languages do have symbols to denote new inputs/new lines. – flawr Mar 15 '16 at 18:03
1  
@flawr It's not an issue. – lirtosiast Mar 15 '16 at 18:04
1 2

You must log in to answer this question.

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