# Can we use Languages/Environments where the answer is computed automatically?

In this question, I found an answer that required no work, as the act of representing the input computed the output, on an extant, non-hypothetical system. Is this legit?

It seemed a lot like using a specifically designed language, but I didn't make this one up. And it does other, general-purpose stuff.

Or, is it using built-in functions to do the work, where my builtin function isn't a function but a chip feature?

• Looks like using built-in functions to do the work to me – John Dvorak Jan 5 '15 at 13:21
• @JanDvorak For the record, that is currently not a valid loophole (although it's only one upvote short). – Martin Ender Jan 5 '15 at 17:23
• @MartinBüttner for the record, I voted against. Maybe let those answers around but not have them egligible for winning? – John Dvorak Jan 5 '15 at 18:41

# This is valid, so long as the I/O is as simple as possible

There are a few ways to get a zero-byte solution. This is one of the more controversial ones, but it isn't automatically unacceptable.

Suppose that the challenge was "concatenate a list of strings", and someone submitted the following program:

# Jelly, 0 bytes

Try it online!

Takes input as a command line argument in the form ["a", "b", "c"]. Output is to standard output.

This is about as legitimate you can get in terms of pure-I/O solutions. The input list is being fed to a Jelly full program in the simplest possible way (and in a very common format for lists of strings even in other languages). Jelly, when outputting a list of strings from a full program, implicitly concatenates them; thus, the resulting output on standard output will be the concatenation of the input lists – and standard output is the simplest, most direct way to get output from a Jelly full program.

When things start going south is when you start having to make assumption about I/O that normally wouldn't be warranted. Say the challenge was "take a list as input; return normally if it has exactly two elements, crash or throw an error/exception otherwise; submit a snippet, you may take input from a variable". Brachylog has a special variable Ċ that's only normally capable of holding lists which have two elements (causing a failure, the equivalent of an exception, if you attempt to assign anything else to it). Can we submit a zero-byte solution that says "Takes input from Ċ"? It would work when run, but it feels a bit like we're encoding the program in something that isn't part of the byte count (specifically, the name of the variable used to store the input). On the other hand, I'd consider the 1-byte snippet Ċ (which assigns the value of ? to Ċ) a valid answer to this, as ? is a distinguished variable intended for providing input to programs, and there are no other variables like it.

As such, I believe that this sort of answer can only be valid if we don't attempt to encode anything in the I/O system. For example, if we take input from a variable, the program should work identically for any valid variable name (with the understanding that the bytecount is measured using the shortest possible name).

One caveat: this answer contradicts our I/O defaults to some extent. For example, allowing I/O via distinguished memory locations is just asking to fall into traps like this, where much of the work of the program can be done in the I/O via picking a specific memory address to use. (However, that answer is highly popular; I'm currently the only downvote on it.) We can fix this either by interpreting our I/O defaults narrowly to say "if I/O via a variable / memory location / register is allowed for a particular language via our I/O defaults, it must work regardless of which variable/location/register of a sort that could reasonably contain the answer is used" (which strikes me as being potentially unobjective), or simply via downvoting/deleting the relevant answers in the I/O defaults thread. I've posted a competing answer here, which should avoid this sort of trouble unless the challenge explicitly overrides the I/O defaults.