# Why do Jelly submissions get to ignore the Y atom in the byte count?

For those not familiar, Y in Jelly joins a list of strings (actually a list of lists of characters) with a newline. In plenty of challenges with text output, Jelly submissions will put Y in the footer on TIO, which I have taken advantage of as well. (TIO with Y).

Without Y the output would be the same text on a single line with no delimiter (TIO without Y).

In the same challenge I linked to there is an 05AB1E submission that returns a list of lines but the lines are clearly delimited in the output as elements of a list. In Jelly, however, any grouping of characters in lists gets ignored in the output.

My question is this: why do Jelly submissions get to forgo counting Y in the byte count if it is necessary to delimit portions of the output?

Not that I want my Jelly answers to have to have one extra byte from time to time, I just don't see the logic behind allowing this.

• Note that in this case you're not allowed to use ³ or ⁴, only ⁸ and ⁹. (because function submission) Apr 5 '18 at 5:59

## 2 Answers

A similar construct is actually visible in other languages, such as my "practical" language of choice C#, and is treated the same way. Here's a really simple challenge to use as an example:

Print this text:

Hello,
world!


Assuming "List of strings" is a valid alternative to "single string with newline delimiter", a simple C# answer might be this:

()=>new[]{"Hello,","world!"}


I think there are better options, but this is a valid solution to the challenge. However, a naive way to display that output like so results in an output of

System.String[]


Which clearly isn't requested! Instead, a slightly more complex footer is needed to translate from "list of strings" to a human-readable format. Just like C#, Jelly (apparently) doesn't naturally format "output this list of strings" in a way that humans would like, so a Footer is added that translates from one entirely valid format to one human readable format.

Hopefully this example with a language that more clearly defines data types clears up that Y isn't used to make the answer valid, only to display a readable output.

• +1, almost exactly what I had in mind. When you have an array in Java (int[]array={1,2,3};) and simply print it with System.out.print(array);, it uses the default Object#toString to print it (i.e. [I@5ccd43c2, where [=array; I=integer; 5ccd43c2=some hexadecimal hashcode value). Using System.out.print(java.util.Arrays.toString(array)); is similar to Jelly's Y (pretty-print builtin) resulting in [1, 2, 3]. Using java.util.stream.IntStream.of(array).forEach(System.out::println); is a custom pretty-print for a new-line delimited output. TIO Apr 6 '18 at 9:33

This would only be valid if the challenge would allow for output as a list of strings anyway. This is allowed on most ASCII-art challenges and was allowed on the one you linked. The solution would still be valid without the Y, it's just there to make the output look prettier.

• The reason I’m not quite convinced by this is that while Jelly represents the output as a list of strings under the hood the output doesn’t and that’s what the user sees Apr 5 '18 at 12:24
• @dylnan Jelly programs are also perfectly usable as Jelly functions. If you consider solutions to be functions rather than programs, the problem disappears.
– user45941
Apr 5 '18 at 13:36