Default for Code Golf: Input/Output methods

Question

It looks like we have a consensus that we want certain defaults for the format which answers are expected in for code-golf. 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.

A method is allowed if it has 5 net votes and at least twice as many upvotes as downvotes.

Answer 1

Programs may output using their return value

Iff it is legit regarding their specs and compilers.

Certain language treat programs as function, allowing programs to communicate via returns. Hence, we shoule allow such programs to be considered as whole, and not as snippet.

Answer 2

Numerical input and output can be given as a character code

For example, the input 64 can instead be given as the character @. This is mainly used for more esoteric languages that can only take input through character codes, for example brainfuck.

Answer 3

An array may be represented as a buffer terminated with a sentinel value

This can be applied to both inputs and outputs for languages such as C and assembly. This is the default for C strings (a buffer of char, terminated with 0), but can be applied to any other data type.

As a more concrete example:

• An input array of positive integers can be taken as a single pointer of uint32_t or any other convenient integer type, which is assumed to terminate with a single zero.
• For an output array of positive integers, a C function can take an output pointer as the start of the buffer, write several numbers on that buffer, and then write a zero at the end.

It should be noted that the sentinel value must be the one that is guaranteed to not appear in any valid input or output, since their presence breaks the premise of the I/O method. For example, if the input may contain zeros, you cannot use zero as the sentinel value for the input array.

Answer 4

A program or function taking input by reference may output by modifying the input value in place

A complement to this

For example, in rust, one might write

fn a(v:&mut Vec<i32>){v.push(7);}

instead of

fn b(mut v: Vec<i32>)->Vec<i32>{v.push(7);return v;}

or

fn c(v:&mut Vec<i32>)->&mut Vec<i32>{v.push(7);return v;} 

Answer 5

Programs may take input from the clipboard

Answer 6

SQL-based languages can output via SELECT or PRINT

We have countless examples of highly upvoted answers sending SQL output to either the results pane (via SELECT) or to the messages pane (via PRINT), depending on which works the best and is shorter for a particular challenge.

Both are acceptable.

(This uses terminology from MS SQL Management Studio, other platforms/clients likely have equivalents.)

Other outputs may be possible as well, such as outputting graphical results to the spatial results pane.

Answer 7

BASIC and related languages may take input via DATA / READ

In various dialects of BASIC, you can include data in the source code by using the DATA statement:

DATA abc, xyz
DATA 2, 3, 5, 7, 11

^{(Examples are written in QBasic because that's what I know.)}

You access this data by using READ:

READ str1$, str2$
FOR i = 1 TO 5
  READ primes(i)
NEXT

This input method is idiomatic for BASIC.

Answer 8

Numerical input and output can be given as a string of digits and vice-versa

As long as the input/output format is consistent, you may take a numerical output such as f(123) as a string f("123") and vice-versa. This will also open up other string methods, such as taking a number as a list of digits as per this consensus.

Note that if different behaviours are expected for numbers with leading zeroes, then you will have to take input as a string instead, since strings with leading zeroes will be mapped to the same number.

You may not add leading zeroes if you are using string input instead of a number.

Answer 9

Image output may consist of a matrix or 2d array for raster images

This is relevant e.g. for graphical-output challenges. (e.g. for languages that otherwise have no way of writing an image file or opening a window for the graphical display)

Answer 10

Spreadsheet languages may output through cell values

Most Excel / Google Sheets answers seem to do this anyway, I don't know why it wasn't here.

For example, this answer outputs a created piece of text to the cell it's pasted into.

Answer 11

Programs may input/output bytes in a bit-serial or 8-bit parallel manner with a clock and enable signal

This is mainly applicable to HDLs such as Verilog, as well as other embedded devices (such as microcontrollers). Currently, $display is capable of writing to standard out in a simulator, but of course, not in a physical FPGA.

Answer 12

Mappings may be used in place of functions

(Discussion in The Nineteenth byte)

Whenever a function is expected, a mapping such as a dictionary/hashmap or array may be used instead.

Arguments for:

• in many languages, there is no syntax difference (K, MATLAB, Ruby - a Proc can be used with the same [] syntax as a Hash)
• disallowing it borders on an unobservable requirement, particularly in the above languages, and having different rules for different languages is generally discouraged
• it allows removing boilerplate in challenges which boil down to "construct a mapping and then look up into it", like (Python) lambda x:{k:v for k,v in ...}[x]

Arguments against:

• it feels a bit cheaty to me

Answer 13

When printing to STDOUT, you may have any number of trailing whitespace

Answer 14

Programs may take input from a generator or iterator

We already have a rule that programs may output via a generator. Just for completeness, I think we should specify it's a valid input method as well.

Example in rust:

|t:Box<dyn Iterator>|t.flatten()

Other example, taking input via the returned generator in python:

def k():
    yield "Hello, "+str(yield "What is your name")

Which can be used like

t = k()
print(next(k))
print(k.send("Charlie"))

Another example:

def k(f):
    return [int(next(f)),*f]

Answer 15

Infinite lists / generators / iterators may be taken as indexing functions

An infinite list / generator / iterator may be taken as a function that indexes into the value.

For example, if taking the infinite list of fibonacci numbers [1, 1, 2, 3, 5, 8] you may instead take a function that:

• When given 0, returns 1
• When given 1, returns 1
• When given 2, returns 2
• When given 3, returns 3
• When given 4, returns 5

etc.

Answer 16

Programs running on FPGAs may take input or give output through transceivers.

Answer 17

Assembly language / machine code must take input and output as defined by an ABI for the platform that predates the challenge

For example, most commonly used ABIs for x86 state that 32-bit integer outputs are returned in the %eax register. As such, that's a valid way to output a 32-bit integer. However, outputting in, e.g., %esp would not be valid, unless a pre-existing ABI can be located where that's considered a valid method of output.

(Some background for people unaware of assembly language technology: an ABI, or Application Binary Interface, is a specification for how pieces of code within a particular program, on a particular platform, communicate with each other via the state of the processor. Most ABIs specify specific memory addresses and/or registers to be used for the communication.)

This is outright intended as a competing answer to the other assembly-language-related answers, because I feel they're too permissive and could lead to loopholes in which bytes are moved from the program to a selection of a register/memory address. (See this answer and the corresponding question for more detail.)

Answer 18

If a program is supposed to take a whole number as input, it may accept the number as a unary string.

Answer 19

Functions may generate different output via different exceptions if they could be caught using different code

For example, in C++, you could use throw 1; and throw true; to output two distinct values. They could be caught by catch(int) and catch(bool) in a try block respectively. (In most other languages, you could only throw values in an exception class.)

Answer 20

Image output may consist of a pixel-shader

A pixel-shader is a function that takes the (x,y) coordinates of a pixel as an input, and outputs the color of this pixel (e.g. a scalar for grayscale images, a tuple for color images, a boolean value for binary images etc.)

This is relevant e.g. for graphical-output challenges. (also for GLSL / Shadertoy answers.)

Answer 21

A natural number may be represented as a collection of n empty collections, and a string as a collection of such numbers

In languages that do not have numbers or strings but do have lists, stacks, or other collections, a natural number (including 0) may be represented by a collection of empty collections, where the length of the outer collection represents the natural number. So [] would represent 0, [[], [], []] would represent 3, and so on. Strings may be represented as collections of these natural numbers, as Unicode codepoints are unsigned.

Answer 22

In stack-based languages, inputs may be pushed onto the stack at the start of the program, and the output may be the top element on the stack at the end of the program

This has already been proposed for functions, but it should also be allowed for full programs.

Answer 23

When returning a set, one can return a map, where values are ignored

Answer 24

A full program may be input or output any time a function could

If we can do this:

x=>y=>x+y

Then we can do this:

print("print(int(input())+"+input()+")")

Answer 25

black-box functions to be taken as input can be assumed to be predefined under a given name only if they cannot be passed as an argument.

This holds for languages that do have classical functions, but cannot pass around functions like other values. This holds for instance for: Java up to version 7

This proposition is the opposite of that one which does not have this restriction.

Answer 26

Functions may output via throwing the output value as an exception, if it could be caught, and read by the code catching the exception

Answer 27

Programs may take input based on their executable name.

i. e. argv[0] in C or $0 in shell-like languages. Thus the script parrot.sh

#!/bin/sh
echo $0

if having multiple links to it

ln parrot.sh foo
ln parrot.sh bar

prints different outputs

PATH=$(pwd) foo     #  will print e.g. /tmp/foo
PATH=$(pwd) bar     #  will print e.g. /tmp/bar

NB: This rule is not applicable if the executable file name has to be a certain string to fulfill the programming challenge’s specifications at hand.

Answer 28

Functions are allowed to overwrite global data structures as its output

The premise of this is that your language does not support built-in return values.

For example, Assembly language doesn't have a built-in way of returning values, therefore a global accumulator is permitted as a return value.

In Scratch, there are no functions (only procedures), therefore global variables are allowed as the output of the function.

In stack-based languages, functions take arbitary items from the stack, and modify the stack. The return value is therefore stored onto the stack.

Answer 29

Output may have any number of leading white space.

There is already a suggestion concerning trailing blanks. This is about preceding blanks. Why should this be acceptable? Suppose you wanna to write a program in Pascal that prints the answer to the ultimate question of life, the universe, and everything. You’ll simply write

program p(output);begin writeLn(42)end.

However, when the destination is a text file (like output is), for numeric write arguments there’s an invisible implementation-defined default minimum-width specifier. Thus this program may print:

         42

i. e. the program is effectively doing a

writeLn(output, 42:11)

The :11 indicates the minimum number of characters the argument occupies (for numeric arguments, for char, string and Boolean it specifies the exact width). The default value is implementation-defined thus different compilers may have different default values, possibly even 1. If leading white space is prohibited you’ll have to write :1 yourself.

Ultimately, like trailing blanks it does not inhibit legibility. Specifically for many numbers it actually improves legibility, that’s why Pascal allows and some compilers do have a reasonably large default minimum-width.

Answer 30

When taking a set, one can take a map from the set to an well agreed value

This allows some languages to easier check if element in a set with mapped value true: X[i] is shorter than X.contains(i)