# Interpreter flags for controlling output: considered cheating?

I'm creating a programming language aimed at code golf puzzles. The language has an internal set of tapes, where the computations are saved and then retrieved to the user.

At the end of the program, the interpreter prints the values on the tapes, and this is considered the result of the computation. However, many problems do not need a set of tapes as an answer, only one tape (in that case, the first tape) or even a single number (the first number in the first tape).

Would it be cheating if I made it possible as an argument during the interpreter execution? Like:

my_interpreter.exe --code '<my-code>' --print-format 1


Of course, I'd like to avoid making it a language function as it would make the results bigger and, therefore, make my language worse in code golf.

I don't consider changing the print format as a calculation step. Also, the default behavior is to print the whole set of tapes, and even when the puzzle expects a single value as result, the value is actually there. It would just print some garbage along the result and I'd like to avoid that.

BUT I need your opinion as well since this language is not just for me. I won't make it an execution argument unless everyone agrees with it. Also, I don't want other code golf language owners to feel cheated.

What do you think about that?

• I guess this might belong on meta? nevertheless, it depends on the challenge, if it allows extra output, fine, if not, you would have to add the "non-standard option" to the byte count of your solution using your language. – Felix Palmen Sep 18 '18 at 14:09
• This might help you. – hyper-neutrino Sep 18 '18 at 14:13
• @HyperNeutrino is this the "official" opinion now? Sounds mostly reasonable, but for a flag as suggested here, it would instantly make this new language an infinite pool of languages... – Felix Palmen Sep 18 '18 at 14:20
• With the proposal of considering different flags as different implementations, flags could be abused to encode more and more of the actual program. Remember MegaGolfScript – Luis Mendo Sep 18 '18 at 14:36
• @FelixPalmen Not official. It's not directly the same, that's why I didn't suggest a dupe. – hyper-neutrino Sep 18 '18 at 14:38
• Alright. I was only aware of the approach to add "non-standard" flags to the byte count. I see the difficulty that this needs a list of "free flags" for many language implementations (e.g. linking flags for a C compiler should probably be free, define flags not ...), but still think it's the fair way ... – Felix Palmen Sep 18 '18 at 15:40
• @LuisMendo According to the link it's called "MetaGolfScript" but I thought "Mega" was way funnier! – dylnan Sep 18 '18 at 16:06

According to our current consensus, this is valid.

There are some concerns raised in the comments:

@HyperNeutrino is this the "official" opinion now? Sounds mostly reasonable, but for a flag as suggested here, it would instantly make this new language an infinite pool of languages...

Comment by Felix Palmen

This is not really a problem - if it leads to low-quality answers, downvotes will serve as quality control.

With the proposal of considering different flags as different implementations, flags could be abused to encode more and more of the actual program. Remember (sic) MegaGolfScript

Comment by Luis Mendo

Sure, but we consider challenges to be more of competitions within languages, rather than competitions across languages, so it would only impact the competition for that exact set of flags, and others who don't care to use such languages aren't affected.

• I'm not entirely convinced here. Although this linked answer has a lot more upvotes than downvotes, is this really enough to call it a consensus? A flag changing the behavior is part of the program logic, and defining it as "creating a new language" is a simple solution, but feels very constructed. Especially with flags that allow an infinite "configuration space", I also see this in conflict with the rule that the language has to exist prior to the challenge. – Felix Palmen Sep 19 '18 at 9:32
• @FelixPalmen There is no such rule anymore that the language must exist prior to the challenge. That was changed a while back. – user45941 Sep 19 '18 at 12:12
• Is there some discussion on this? It's IMHO an unfortunate decision, opening up the possibility to tailor a language specifically for a challenge. But even without that rule, a different flag making a different language still feels wrong, stressing the definition of what makes a "language" way too far. Well, that's my opinion ... – Felix Palmen Sep 19 '18 at 13:29
• @FelixPalmen The discussion is on meta - I can't find/link it right now because mobile. And as for quality concerns - that's what downvotes are for. – user45941 Sep 19 '18 at 13:31
• @FelixPalmen I think this is what you're looking for. – JayCe Sep 19 '18 at 14:37
• @FelixPalmen Except on answer-chaining challenges. – user202729 Sep 19 '18 at 15:10
• @FelixPalmen I'm pretty sure it's a consensus not because it has a high score, but because it has a greater score than what was the consensus before. – Erik the Outgolfer Sep 19 '18 at 15:20

# C - 19 bytes

#include<stdio.h>
C


Output:

Make it as a function of the language. Interpreter parameters are way too easy to abuse.


Compile and run with:

gcc -DC="int main(){printf(\"Make it as a function of the language. Interpreter parameters are way too easy to abuse.\");return 0;}" cheat.c && ./a.out

• I know this illustrates the problems with our current approach, but it doesn't actually suggest any possible solutions – Jo King Sep 27 '18 at 17:13
• @JoKing I suggested it to be made as a function of the language instead of option in the interpreter. For example if you were extending brainfuck to have 10 tapes instead of 1, you could set numbers from 0-9 to switch to a tape etc. – FatalError Sep 27 '18 at 19:51
• Aren't flags already a function of the language? I don't really understand what you intend. What would be the bytecount of your code under your suggested rules? – Jo King Sep 29 '18 at 6:07
• @JoKing 138. Obviously. – FatalError Sep 30 '18 at 21:17