7
\$\begingroup\$

I'm creating a programming language aimed at code golf puzzles. The language has an internal set of tapes, where the computations are saved and then retrieved to the user.

At the end of the program, the interpreter prints the values on the tapes, and this is considered the result of the computation. However, many problems do not need a set of tapes as an answer, only one tape (in that case, the first tape) or even a single number (the first number in the first tape).

Would it be cheating if I made it possible as an argument during the interpreter execution? Like:

my_interpreter.exe --code '<my-code>' --print-format 1

Of course, I'd like to avoid making it a language function as it would make the results bigger and, therefore, make my language worse in code golf.

I don't consider changing the print format as a calculation step. Also, the default behavior is to print the whole set of tapes, and even when the puzzle expects a single value as result, the value is actually there. It would just print some garbage along the result and I'd like to avoid that.

BUT I need your opinion as well since this language is not just for me. I won't make it an execution argument unless everyone agrees with it. Also, I don't want other code golf language owners to feel cheated.

What do you think about that?

\$\endgroup\$
7
  • 7
    \$\begingroup\$ I guess this might belong on meta? nevertheless, it depends on the challenge, if it allows extra output, fine, if not, you would have to add the "non-standard option" to the byte count of your solution using your language. \$\endgroup\$
    – Felix Palmen
    Commented Sep 18, 2018 at 14:09
  • 7
    \$\begingroup\$ This might help you. \$\endgroup\$
    – hyperneutrino Mod
    Commented Sep 18, 2018 at 14:13
  • 2
    \$\begingroup\$ @HyperNeutrino is this the "official" opinion now? Sounds mostly reasonable, but for a flag as suggested here, it would instantly make this new language an infinite pool of languages... \$\endgroup\$
    – Felix Palmen
    Commented Sep 18, 2018 at 14:20
  • 3
    \$\begingroup\$ With the proposal of considering different flags as different implementations, flags could be abused to encode more and more of the actual program. Remember MegaGolfScript \$\endgroup\$
    – Luis Mendo
    Commented Sep 18, 2018 at 14:36
  • \$\begingroup\$ @FelixPalmen Not official. It's not directly the same, that's why I didn't suggest a dupe. \$\endgroup\$
    – hyperneutrino Mod
    Commented Sep 18, 2018 at 14:38
  • \$\begingroup\$ Alright. I was only aware of the approach to add "non-standard" flags to the byte count. I see the difficulty that this needs a list of "free flags" for many language implementations (e.g. linking flags for a C compiler should probably be free, define flags not ...), but still think it's the fair way ... \$\endgroup\$
    – Felix Palmen
    Commented Sep 18, 2018 at 15:40
  • 1
    \$\begingroup\$ @LuisMendo According to the link it's called "MetaGolfScript" but I thought "Mega" was way funnier! \$\endgroup\$
    – dylnan
    Commented Sep 18, 2018 at 16:06

2 Answers 2

Reset to default
6
\$\begingroup\$

According to our current consensus, this is valid.

There are some concerns raised in the comments:

@HyperNeutrino is this the "official" opinion now? Sounds mostly reasonable, but for a flag as suggested here, it would instantly make this new language an infinite pool of languages...

Comment by Felix Palmen

This is not really a problem - if it leads to low-quality answers, downvotes will serve as quality control.

With the proposal of considering different flags as different implementations, flags could be abused to encode more and more of the actual program. Remember (sic) MegaGolfScript

Comment by Luis Mendo

Sure, but we consider challenges to be more of competitions within languages, rather than competitions across languages, so it would only impact the competition for that exact set of flags, and others who don't care to use such languages aren't affected.

\$\endgroup\$
7
  • 1
    \$\begingroup\$ I'm not entirely convinced here. Although this linked answer has a lot more upvotes than downvotes, is this really enough to call it a consensus? A flag changing the behavior is part of the program logic, and defining it as "creating a new language" is a simple solution, but feels very constructed. Especially with flags that allow an infinite "configuration space", I also see this in conflict with the rule that the language has to exist prior to the challenge. \$\endgroup\$
    – Felix Palmen
    Commented Sep 19, 2018 at 9:32
  • 1
    \$\begingroup\$ @FelixPalmen There is no such rule anymore that the language must exist prior to the challenge. That was changed a while back. \$\endgroup\$
    – user45941
    Commented Sep 19, 2018 at 12:12
  • 1
    \$\begingroup\$ Is there some discussion on this? It's IMHO an unfortunate decision, opening up the possibility to tailor a language specifically for a challenge. But even without that rule, a different flag making a different language still feels wrong, stressing the definition of what makes a "language" way too far. Well, that's my opinion ... \$\endgroup\$
    – Felix Palmen
    Commented Sep 19, 2018 at 13:29
  • 3
    \$\begingroup\$ @FelixPalmen The discussion is on meta - I can't find/link it right now because mobile. And as for quality concerns - that's what downvotes are for. \$\endgroup\$
    – user45941
    Commented Sep 19, 2018 at 13:31
  • \$\begingroup\$ @FelixPalmen I think this is what you're looking for. \$\endgroup\$
    – JayCe
    Commented Sep 19, 2018 at 14:37
  • \$\begingroup\$ @FelixPalmen Except on answer-chaining challenges. \$\endgroup\$
    – user202729
    Commented Sep 19, 2018 at 15:10
  • \$\begingroup\$ @FelixPalmen I'm pretty sure it's a consensus not because it has a high score, but because it has a greater score than what was the consensus before. \$\endgroup\$
    – Erik the Outgolfer
    Commented Sep 19, 2018 at 15:20
0
\$\begingroup\$

C - 19 bytes

#include<stdio.h>
C

Output:

Make it as a function of the language. Interpreter parameters are way too easy to abuse.

Compile and run with:

gcc -DC="int main(){printf(\"Make it as a function of the language. Interpreter parameters are way too easy to abuse.\");return 0;}" cheat.c && ./a.out
\$\endgroup\$
4
  • \$\begingroup\$ I know this illustrates the problems with our current approach, but it doesn't actually suggest any possible solutions \$\endgroup\$
    – Jo King Mod
    Commented Sep 27, 2018 at 17:13
  • \$\begingroup\$ @JoKing I suggested it to be made as a function of the language instead of option in the interpreter. For example if you were extending brainfuck to have 10 tapes instead of 1, you could set numbers from 0-9 to switch to a tape etc. \$\endgroup\$
    – FatalError
    Commented Sep 27, 2018 at 19:51
  • \$\begingroup\$ Aren't flags already a function of the language? I don't really understand what you intend. What would be the bytecount of your code under your suggested rules? \$\endgroup\$
    – Jo King Mod
    Commented Sep 29, 2018 at 6:07
  • \$\begingroup\$ @JoKing 138. Obviously. \$\endgroup\$
    – FatalError
    Commented Sep 30, 2018 at 21:17

You must log in to answer this question.

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