Potential execution flag rule break

Question

I am currently developing a golfing language for a specific type of task. I was hoping to use some command line flags for different options in the language. Since the language is intended to be a golfing language I thought I would try to make these additional flags as cheap as possible.

The first idea I had was to make a -r flag that is required to run all programs so that adding additional flags would cost only one additional byte, as per the meta-consensus (in this question):

[Extra command line flags are counted] as a difference in character count to the shortest equivalent invocation without them.

Reading this rule I had another idea. I maintain the -r flag but make it redundant when other flags are present (e.g. -a is the same as -ra). That way the first flag is free.

However you can go even further, you can require an option

--thisisareallylongflagnamerequiredforstandardexecutionbutredundantwhenotherflagsarepresentitexistsentirelytosavebytesinaddingnewcommandlineargumentsbecausethemetarulesonprogrammingpuzzlesandcodegolfstackexchangewerenotdesignedtohandlesuchedgecasesmakingreallylongstandardflagsveryadvantageousforgolfing

and require it to run programs normally but consider it redundant when other flags are preset. This would be the current reading of the rules allow you to use pretty much every command line flag you want for free, for a more strict reading of the rules it would even allow for negative scores in code-golf. I could make it so that programs can be embedded in the command line arguments thus making a language that can obstensibly solve every challenge on ppcg in zero (or less bytes).

Surely this is not what was intended by the rules. What should we do to prevent this type of shenanigan?

Answer 1

What should we do to prevent this type of shenanigan?

Firstly, we should all solemnly commit to downvoting every answer we see in a language which is deliberately designed to try to exploit PPCG-specific loopholes. This kind of rules-lawyering funny-at-most-once loophole-seeking is bad sportsmanship and detrimental to the site.

---

Secondly, I think that a close reading of the cited consensus gives an argument that this doesn't work anyway:

Compare

I maintain the -r flag but make it redundant when other flags are present (e.g. -a is the same as -ra). That way the first flag is free.

with

options to request different behaviors from the interpreter. This is the n/p/l/a/f family of options in perl/sed/awk/ruby. I count those as a difference in character count to the shortest equivalent invocation without them.

On a narrow reading, this only applies to a handful of languages. On a moderate reading it can be generalised to other situations which have additive flags. But to generalise it to subtractive flags should require a good justification that that was the intent, and I can't see that justification.

The other answer, although it's newer and only at +4/-0 rather than +18/-2, is also worth taking into account. It explicitly says "Every Additional Command Line Byte" (my emphasis).

Given that both answers are written thinking about languages with standard UNIX-style command-line parsing (Perl, PHP, ...), I think that should be assumed when interpreting intent and resolving ambiguities.

• Changing -r to -a is really removing the flag and inserting a new one, and the new one should be scored at full cost. The question of how removing the old one should be scored is a separate issue, and about as urgent an issue as the question of how many angels can dance on the head of a pin. Quite simply: the fact that the issue has never come up before strongly suggests that there aren't any notable existing languages which have such subtractive flags, and if anyone is thinking of creating one solely for the purpose of having a meta discussion on how to score it, they should find more entertaining ways of wasting other people's time.
• If -rrrr1rr doesn't behave in the same way as -r -r -r -r -1 -r -r (and -r -1 -r -r -r -r -r, etc.: the only flag whose position may be significant when combining single-letter flags is the final one, if it takes arguments) then changing -rrrrrr to -rrrr1rr is adding a new 8-byte flag and should be scored as 9 bytes.

Answer 2

I'm starting to think that our general rule for byte counting, etc., is all wrong.

First, a thought experiment. I think the fairest way to compare programs would be like this: for each language, we define an infinite sequence that contains all possible programs in that language (taking into account compiler flags, nonstandard conditions, and everything else that might affect the way the program runs). Then each program is scored by its position in the sequence. In most cases, the sequence would/could just come down to "sort all possible programs by their length in bytes" and lead to approximately the same scores we have now, but languages that intentionally went for this sort of shenanigans would find the score much worse.

That said, I suspect we probably shouldn't/can't move to a system like this; it's much harder to understand than the present system, even if it is a lot fairer and less exploitable, and it'd therefore make it much harder for new users to join the site. However, it's a good test to use to judge whatever actual scoring rules we come up with to see if they make sense or not.

We can apply these general principles to this case. In this case, we learn that what's important is that the score penalty for changing command-line options is based on the kolmogorov-complexity of those changes. In the case of adding options, that's trivial (as even uncompressed, the changes take up no more space than the options themselves), but when deleting or editing options, the number of deleted/edited bytes is clearly capable of being an underestimate of the number of bytes required to specify the change.

Perhaps the best solution is to define language variants in which the command-line options for the language are somehow part of the program itself. (This is what, e.g., Anarchy Golf does for Perl, which makes heavy use of options.) This is along similar lines to defining a new encoding, or a new I/O wrapper around a language, or whatever. As far as I can tell, this would prevent all possible forms of cheating, while still being fairly easy to understand.

Answer 3

The simplest rule to apply would be "don't take the mickey".

If a language sometimes requires a flag which does absolutely nothing, it's clearly trying to game the rules. So your idea for -r / -a would be a no-go. You'd basically be getting a byte of code for free.

If a language always requires a flag, that's OK. So your original -r / -ra is no problem. In fact, my view is that we shouldn't count the <space>- as extra chars even for languages that don't always require a flag.

If a language has a "flag" which can be adjusted to vary the program in more ways than the code itself (your 1000 rs suggestion on Mego's answer), then it's not a flag; it's an alternative input format for the code. You can't just put a - in front of something and call it a flag.

Finding explicit rules for this stuff will always leave loopholes, but common sense can trivially judge them on a case-by-case basis.

Answer 4

A practical rule proposal

I think that there are some problems with the current rules for counting flags. The simple fact that adding a mandatory flag to a language improves the bytecount of answers in that language that use other flags seems quite wrong to me. Another example is the case of ><>, where the -v flag is useful in a lot of situations but costs 3 bytes since there is no other argument that can be used for free.

So, the simple rule I'm proposing is:

All flags are counted as if they were part of the source. The - prefix is ignored.

I think this should be the general rule, straight and simple. Then, we could make per-language exceptions to ignore those flags that are mandatory or always used in practice, to avoid punishing languages like Jelly.

In the language of the question, the r flag could be listed as an exception and not counted. A submission using -ar would have its bytecount increased by +1, exactly like one using just -a. (Since you were adding -r exclusively to render other flags cheaper, though, you could consider simply not implementing it)

Answer 5

I propose an alternative rule:

Non-standard flags for compilation and/or execution incur a penalty equal to the Levenshtein distance from the nearest standard execution.

This would not change the byte penalty in many cases (-abc would still be +2 bytes if the standard is -a), but it would prevent such abuses like the one in the question.