19
\$\begingroup\$

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.

\$\endgroup\$
2
  • 18
    \$\begingroup\$ 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) \$\endgroup\$
    – MercyBeaucou
    Dec 7, 2017 at 22:26
  • 1
    \$\begingroup\$ @MildlyMilquetoast: It'll get banned for the same reason metagolfscript got banned. \$\endgroup\$
    – Joshua
    Mar 4, 2019 at 17:19

1 Answer 1

Reset to default
55
\$\begingroup\$

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 (barring other rules like storing data in the filename). 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.
\$\endgroup\$
18
  • 1
    \$\begingroup\$ 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. \$\endgroup\$
    – Erik the Outgolfer
    Dec 8, 2017 at 12:29
  • 3
    \$\begingroup\$ @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. \$\endgroup\$
    – user45941
    Dec 8, 2017 at 14:00
  • 3
    \$\begingroup\$ This is a very elegant solution. \$\endgroup\$
    – Οurous
    Dec 9, 2017 at 2:37
  • 1
    \$\begingroup\$ Related. How would you deal with that? \$\endgroup\$
    – DELETE_ME
    Dec 9, 2017 at 12:26
  • 2
    \$\begingroup\$ @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. \$\endgroup\$
    – user45941
    Dec 9, 2017 at 12:29
  • 1
    \$\begingroup\$ 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? \$\endgroup\$
    – DELETE_ME
    Dec 9, 2017 at 12:34
  • 3
    \$\begingroup\$ @user202729 Passing code as program flags wouldn't be expressly prohibited - that would be an example of "cheating flags". \$\endgroup\$
    – user45941
    Dec 9, 2017 at 12:35
  • 1
    \$\begingroup\$ 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. \$\endgroup\$
    – DLosc
    Dec 15, 2017 at 6:22
  • 3
    \$\begingroup\$ @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. \$\endgroup\$
    – user45941
    Dec 15, 2017 at 7:53
  • 6
    \$\begingroup\$ Does this only apply to argument-flags? Or would required imports, like Java 8 with import java.util.* also apply to this? \$\endgroup\$
    – Kevin Cruijssen
    Feb 1, 2018 at 15:19
  • 4
    \$\begingroup\$ 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 \$\endgroup\$
    – Ton Hospel
    Feb 20, 2018 at 18:49
  • 3
    \$\begingroup\$ @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. \$\endgroup\$
    – user45941
    Feb 20, 2018 at 19:23
  • 1
    \$\begingroup\$ So an empty program running with python -e "...do a bunch of stuff..." counts as 0 bytes? That's ridiculous. \$\endgroup\$
    – user253751
    Nov 2, 2020 at 13:15
  • 2
    \$\begingroup\$ @user253751 I think that would be an unfunny loophole \$\endgroup\$
    – pxeger
    Nov 4, 2020 at 15:33
  • 3
    \$\begingroup\$ @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. \$\endgroup\$
    – user253751
    Nov 4, 2020 at 16:36

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .