2 Clarify re subtractive flags
source | link

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. So changing -r to -a is really removing the flag and inserting a new one, and the new one should be scored at full cost. Moreover, 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.

  • 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.

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. So changing -r to -a is really removing the flag and inserting a new one, and the new one should be scored at full cost. Moreover, 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.

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.
1
source | link

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. So changing -r to -a is really removing the flag and inserting a new one, and the new one should be scored at full cost. Moreover, 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.