20
\$\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
  • 19
    \$\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

2 Answers 2

Reset to default
56
\$\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
2
\$\begingroup\$

Commonly used flags are free, unique flags/flag combinations are not

Essentially, the flag problem comes down to differentiating two scenarios. At one extreme, we have languages which are often invoked using certain flags. At the opposite extreme, we have flags or flag combinations which have never been seen prior to a given answer. To me, commonly used flags should be legal, and should cost no bytes. Unique flags, ones which are not commonly used, should be treated the same as code. For instance, in this answer, the flag combination Rss is unique, and should be counted as code, requiring 3 bytes.

The previous answer says that each flag combination is its own language. But that's a bit of a cop-out, because now we essentially have users inventing new languages constantly, without a clear judgement on when that is allowed or not. Referring to this standard loophole, we see that inventing a language for the purpose of a solution is already banned. Read literally, the combination of these two rulings would imply that using unique flag combinations constitutes inventing a language for a challenge, and is therefore banned outright.

I don't think banning unique flag combinations outright is correct, and I don't think allowing them for free is correct. I think the best solution is to count them as code. Note that the - at the beginning of the flag invocation is common to most flags, and therefore is free.

However, this raises the question: How can we objectively determine which flags and flag combinations are common, and which are unique? I think we should do this in the same way we determine whether a programming language exists prior to a challenge, or is made up for the challenge. Ask: "Is this flag or flag combination something that people have used previously? Used purposefully, not just to overcome this rule?" There might be some edge cases requiring subjectivity, but it will almost always be clear.

\$\endgroup\$
1
  • 5
    \$\begingroup\$ I agree with most of this post, except the part that some flags need to be counted in the score. Scoring flags is a can of worms on its own; there had always been an argument about things like "do we count spaces before a -x flag?". IMO, our current flag rule is a good enough compromise. The most blatant cases are ruled out by the "made-up language" loophole, and the rest are only subjectively cheaty; you can downvote an answer that looks cheaty and/or uninteresting. \$\endgroup\$
    – Bubbler
    May 19 at 2:33

You must log in to answer this question.

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