# Command-line flags on front ends

Our standard policy regarding command-line flags states that one should count the space before the dash (-) too, when there aren't any "free" options, since it doesn't exist in the shortest possible invocation. For example this:

language -option program.p


is 8 bytes longer than the shortest possible invocation being:

language program.p


However, in TIO, you don't include a space and instead click a button to add an argument. Also, you don't need to escape it either. This may apply to other online interpreters as well.

One could say that TIO is an implementation of a language, and therefore you can use flags at a lower cost. However, another opinion may be that it's just a front end and doesn't count as an implementation.

So the question is, how should we handle a situation where a front end automatically handles command-line flags with less separators and escaping? Count just like if we use the underlying interpreter directly or not?. Please note that this doesn't apply to "free" flags like Perl's -e, which shouldn't be counted anyways. Also, this question isn't about the front end being an implementation of a language itself, apart from the interpreter used underneath (e.g. interpreter wrappers with special configuration).

This question was inspired by Οurous's doubt for what is being asked here.

• I can imagine being able to make a language on TIO that is essentially unary, but instead of the number of bytes in the program, it looks at however many blank command line arguments are present. (i.e. click the plus however many times you need instead of adding 0s to the program) – MercyBeaucou Dec 7 '17 at 22:26
• @MildlyMilquetoast: It'll get banned for the same reason metagolfscript got banned. – Joshua Mar 4 '19 at 17:19

## Let's solve the flag problem once and for all

Rather than dealing with inconsistent schemes for adding flags, let's just consider each separate invocation of a compiler/interpreter/whatever a separate implementation (and thus a separate language by our rules).

This comes with many benefits:

1. The use of "cheating" flags is less useful, because using those flags means you're using a different language, and thus are competing only with those solutions who also use the same "cheating" flags.
2. It is most consistent with our policy on implementations defining the language. If we view an implementation as a program that takes input and transforms it into output, then it is perfectly reasonable to consider each combination of flags as a different implementation, because the flags change how input is transformed into output - just as we would consider a different program to be a different implementation.
3. Byte count would solely be dependent on the size of the code. This is much more reasonable than having to consider how many extra bytes various flags cost by comparing each invocation to a "standard" invocation.
4. This brings languages like C, where external libraries need to be specified on the command line (e.g. -lncurses) in line with languages like Python, where external libraries don't need to be explicitly specified via command-line arguments (if the package is installed, you can import it). This removes an unnecessary penalty for languages without automatic library discovery (and other similar features of which the absence necessitates additional command line arguments).
5. We don't need a list of rules for which flags are free versus which flags aren't. This lowers the barrier for participation for users who are not aware of all of our rules. When the obvious solution is the correct solution, new users can participate more easily.
• By far, I think this is a good approach. However, how should we handle flags such as C's -lncurses (i.e. link the ncurses library)? Count is as 7 bytes (ncurses) or not? The thing is, we normally do count imports in the code, so I'm not really clear on how should I handle import-type flags. – Erik the Outgolfer Dec 8 '17 at 12:29
• @EriktheOutgolfer Just as you would call the language "C + ncurses" now, the same goes for my proposal. "C + ncurses" would be the C language where -lncurses has been passed to the linker. – user45941 Dec 8 '17 at 14:00
• This is a very elegant solution. – Οurous Dec 9 '17 at 2:37
• Related. How would you deal with that? – user202729 Dec 9 '17 at 12:26
• @user202729 As Wheat Wizard said in this, the challenge rules would have to keep the various flag options in mind, just like they have to deal with the various versions of the same language in mind. It makes things a bit more complicated for answer-chaining authors, but that's a fair tradeoff to me. – user45941 Dec 9 '17 at 12:29
• So... flags are free, and answer-chaining rules need to define explicitly? Still, a lot of languages can pass program code on flags... although it's easy to recognize it, how would you define it objectively? – user202729 Dec 9 '17 at 12:34
• @user202729 Passing code as program flags wouldn't be expressly prohibited - that would be an example of "cheating flags". – user45941 Dec 9 '17 at 12:35
• Say I write a 20-byte Pip submission that uses the -n flag for output formatting. Currently, my header would be Pip, 21 bytes, with a note about the flag underneath. Under this proposal, would my header be Pip with -n flag, 20 bytes? Seems clunky. – DLosc Dec 15 '17 at 6:22
• @DLosc It's much less clunky than trying to decide a default set of flags for each language, and then determining how many additional "bytes" to add for deviations from that standard. – user45941 Dec 15 '17 at 7:53
• Does this only apply to argument-flags? Or would required imports, like Java 8 with import java.util.* also apply to this? – Kevin Cruijssen Feb 1 '18 at 15:19
• I feel this doesn't work very well for perl where you can create many equivalent solutions with minor flag variations (e.g. pop vs -n with <> or \$_. Picking the right input format with the right flags is part of the fun of crafting a perl solution and I dislike that all these variations would count as different languages. It also works badly with options like -F and -i where the arguments aren't really code but you can stuff a lot of very useful data (mostly regexes). And you want that allowed since it's the natural thing to do for many questions – Ton Hospel Feb 20 '18 at 18:49
• @TonHospel While that approach may work fine for Perl, it causes problems when other languages are considered, as evidenced by the multitude of questions on meta regarding command-line flags. Since PPCG aims to be inclusive of programming languages, a more general rule needs to be applied. – user45941 Feb 20 '18 at 19:23
• So an empty program running with python -e "...do a bunch of stuff..." counts as 0 bytes? That's ridiculous. – user253751 Nov 2 '20 at 13:15
• @user253751 I think that would be an unfunny loophole – pxeger Nov 4 '20 at 15:33
• @pxeger so the challenge is redefined as: get as close to python -e "solve_challenge()" -e "eval(input())" as you can, before it becomes an unfunny loophole. Scored in bytes. – user253751 Nov 4 '20 at 16:36