15
\$\begingroup\$

So, in the last couple months, I have seen several (especially JavaScript) quines told that they are cheating because they stringify a function. Accordingly, I thought that was the standard - it's reading its source, of course it's cheating.

Wikipedia's section on cheating quines includes the following as an example of reading source, and therefore, cheating:

function a() {
    document.write(a, "a()");
}
a()

The accepted answer on the "proper quine" question states that

Furthermore, a quine must not access its own source, directly or indirectly.

However, there are several answers posted since then, on "Golf you a quine for great good", that read a JavaScript function's source, such as this one.

So, the question is: Is fetching a function's source cheating in a quine?

\$\endgroup\$
7
  • \$\begingroup\$ Related, Related \$\endgroup\$
    – Stephen
    Aug 8, 2017 at 17:51
  • \$\begingroup\$ I'd just like to point out that literally every other quine in Wikipedia's "cheating quine" section directly or indirectly accesses the entire file that it's stored in; the JS one arguably shouldn't even be there. \$\endgroup\$
    – ETHproductions
    Aug 18, 2017 at 21:21
  • \$\begingroup\$ Please see my comments on Dennis' answer. I am 100% convinced that answer is incorrect. Or at least, it contradicts the PPCG definition of a proper quine, so that definition and Dennis' answer cannot simultaneously be policy. \$\endgroup\$
    – N. Virgo
    Apr 29, 2018 at 13:12
  • \$\begingroup\$ @Nathaniel What can you say against "the "a()" encodes the a() at the end"? \$\endgroup\$
    – DELETE_ME
    May 2, 2018 at 12:47
  • \$\begingroup\$ @user202729 I can say nothing against that; it isn't the issue. The proper quine definition has two parts. The first, It must be possible to identify a section of the program which encodes a different part of the program, is satisfied by this quine, no problem. But the second, Furthermore, a quine must not access its own source, directly or indirectly, is quite clearly not. \$\endgroup\$
    – N. Virgo
    May 2, 2018 at 13:39
  • \$\begingroup\$ @dylnan I unaccepted, will leave it unanswered for now \$\endgroup\$
    – Stephen
    Jul 26, 2018 at 20:23
  • \$\begingroup\$ Related: Loopholes that are forbidden by default \$\endgroup\$
    – Mast
    Nov 9, 2021 at 19:12

3 Answers 3

Reset to default
16
\$\begingroup\$

Yes, it is cheating.

We have to remember the original inspiration of a quine, as taken from GEB, is that it's indirect self-reference. In other words, code isn't directly allowed to refer to its own function objects. Otherwise the shortest quine in English would be "me" or "this phrase" or some appropriate variant.

\$\endgroup\$
9
  • 1
    \$\begingroup\$ So just to clarify, the CJam quine {"_~"}_~ is cheating by this definition? \$\endgroup\$
    – ETHproductions
    Aug 18, 2017 at 2:15
  • \$\begingroup\$ @ETHproductions Yes, I claim it is cheating. \$\endgroup\$
    – Neil
    Aug 18, 2017 at 7:58
  • 1
    \$\begingroup\$ I'm not sure I agree with this definition. In most languages the only differences between a function and a string are 1) the string representation of a function usually includes all formatting necessary to just re-include the output in source code (in some languages this requires a built-in, and there's usually a built-in for getting the representation of a string too), and 2) the method to evaluate them is somewhat different (and in some languages, e.g. CJam, even that is the same). E.g., compare the JS quines e=_=>alert('e='+e+';e()');e() and e="alert('e='+uneval(e)+';eval(e)')";eval(e). \$\endgroup\$
    – ETHproductions
    Aug 18, 2017 at 21:03
  • 1
    \$\begingroup\$ @ETHproductions So the only way to enforce indirect self-reference is to ban eval quines too? (Although that is beyond the scope of this meta question.) \$\endgroup\$
    – Neil
    Aug 18, 2017 at 23:18
  • 1
    \$\begingroup\$ That hadn't been my original thought, but the more I think about it the more correct that seems. On their own, both functions and strings are just literals; trouble only occurs when either are evaluated. Consider the quine f=_=>alert("f="+f+";"+(f+"").slice(3));alert("f="+f+";"+(f+"").slice(3)): although it reads a function's source, it's hardly different than the standard quine template that manipulates one main string to get the entire source code. IMHO we should allow or disallow evaluating a function/string/etc. as code, rather than simply disallowing reading a function's source. \$\endgroup\$
    – ETHproductions
    Aug 19, 2017 at 0:16
  • 1
    \$\begingroup\$ BTW, I am a supporter of disallowing self-referencing functions if functions are allowed as answers to the challenge. In the same way that full-program quine entries are never allowed to access their full source, function quine entries should not be allowed to access their full source. For example, I would not consider function a(){return""+a} a valid quine even if function entries were allowed. \$\endgroup\$
    – ETHproductions
    Aug 19, 2017 at 0:21
  • 1
    \$\begingroup\$ @ETHproductions I believe that currently functions are usually not accepted as quines (at least not in the "Golf you a Quine for Great Good" question), although I can't find anything definitive on that \$\endgroup\$
    – Stephen
    Aug 19, 2017 at 2:23
  • \$\begingroup\$ @StepHen That's why I said "if functions are allowed as answers to the challenge" \$\endgroup\$
    – ETHproductions
    Aug 19, 2017 at 2:26
  • \$\begingroup\$ @ETHproductions My latest idea: you must be able to port the quine. Outline example: fictional language in which "qscdpp"qscdpp is a quine; 05AB1E port: "qscdpp"'"s«D??. Note that the port still prints the original quine of course. \$\endgroup\$
    – Neil
    May 3, 2018 at 0:07
13
\$\begingroup\$

It's not a cheating quine

The meta post you quote contains the following example of a proper quine in CJam.

{"_~"}_~

{"_~"} defines a block (anonymous function). It won't be executed, so it's left on the stack and printed implicitly when the program finishes. The following _~ pushes a copy of the block and executes it, pushing the string _~ on the stack.

In synthesis, it defines a function, prints the function, then prints the code that executes the function. This is exactly what your example in the question does, so it is every bit as valid as the CJam quine, which is valid by community consensus.

Reading a function's source is indirectly reading part of the source of the program

It is not. The JavaScript quine defines a function and manipulates its string representation. This is no different from defining a string and printing and eval-ing that string, which is what the shortest quines in most interpreted languages do.

As long as you don't access the source code of your program (rather that using string representations of parts thereof), you're not violating our definition.

\$\endgroup\$
13
  • 6
    \$\begingroup\$ I like this post. I've always had a problem with "directly or indirectly", since all strings indirectly read portions of the source code, and they are obviously allowed for quines. Getting a function representation is no less valid than getting a string representation. +1 \$\endgroup\$
    – Conor O'Brien
    Aug 8, 2017 at 19:05
  • 1
    \$\begingroup\$ The difference between your CJam code and the JavaScript code is that CJam never reads the code it's executing, while the JS reads itself while running. My definition of a cheating quine would be a program which at some point reads the same code that it's executing plus at least one surrounding character. \$\endgroup\$
    – dzaima
    Aug 8, 2017 at 19:19
  • 1
    \$\begingroup\$ @dzaima The difference is that CJam interpreter executes the analog of document.write(a) implicitly when the program finishes. I don't consider this a meaningful difference. If the defined block printed itself explicitly, it would still be valid. \$\endgroup\$
    – Dennis
    Aug 8, 2017 at 19:23
  • \$\begingroup\$ @Dennis the problem with that is that if I made a language which has the whole source code as a function and it instantly calls it then I could, by reading the source of the function (aka the whole program), read the whole source code. \$\endgroup\$
    – dzaima
    Aug 8, 2017 at 19:32
  • \$\begingroup\$ So, f=_=>"f="+f is now a valid JS quine? Sweet! \$\endgroup\$
    – Shaggy
    Aug 9, 2017 at 10:46
  • \$\begingroup\$ @Shaggy that's basically the exact quine that is currently winning the quine thread for JavaScript, except that the quine thread explicitly states that you have to print the output. \$\endgroup\$
    – Stephen
    Aug 9, 2017 at 14:07
  • \$\begingroup\$ All those deleted solutions and challenges I just didn't participate in because people kept telling me that stringifying a function constituted a cheating quine :( \$\endgroup\$
    – Shaggy
    Aug 10, 2017 at 10:54
  • \$\begingroup\$ @Shaggy well everybody was wrong :P there are a lot of deleted JS quines like this \$\endgroup\$
    – Stephen
    Aug 11, 2017 at 19:31
  • \$\begingroup\$ This seems to allow def printFunc(){return str(printFunc)} (assuming str returns the string representation of the function). Am I correct? \$\endgroup\$
    – Nathan Merrill
    Aug 17, 2017 at 19:39
  • 2
    \$\begingroup\$ @NathanMerrill I believe most quine problems require printing of the source, not just a function return. \$\endgroup\$
    – Stephen
    Aug 18, 2017 at 14:44
  • 4
    \$\begingroup\$ This answer is so utterly wrong, it's frustrating. In the context of proper quines, defining a function and then accessing its string representation (i.e. its source) is different from defining a string and printing and eval-ing that string. In one case you go from code to data and in the other from data to code. That difference is precisely what defines "cheating" when it comes to quines. This answer should not be upvoted or accepted, as it opens up a huge loophole in quine challenges. \$\endgroup\$
    – N. Virgo
    Apr 27, 2018 at 14:24
  • 2
    \$\begingroup\$ I mean, with this as accepted policy, the PPCG quine rules amount in practice to "you are not allowed to read your own source code, directly or indrectly, except if you're using Javascript, in which case you are." I think this is a very silly situation. \$\endgroup\$
    – N. Virgo
    Apr 27, 2018 at 14:28
  • 3
    \$\begingroup\$ Also it's leading to situations like this one, where people are arguing that they are allowed to use feature that let them read their own source code, on the grounds that such functions are similar to the feature in Javascript that lets you read your own source code, which for some reason is allowed. Who can blame them really - it would be inconsistent to allow this in Javascript but not other languages. The only problem is that we have a perfectly good set of rules for proper quines that completely contradict that. \$\endgroup\$
    – N. Virgo
    Apr 27, 2018 at 14:32
12
\$\begingroup\$

Yes, it is cheating

According to the "proper quine"-meta post:

a quine must not access its own source, directly or indirectly.

Reading a function's source is indirectly reading part of the source of the program, therefore it is cheating, according to the current meta consensus.

\$\endgroup\$
3
  • 5
    \$\begingroup\$ I feel like the same argument could be extended to say "string literals are not allowed in a quine because any string in a program is a part of the program's source, and therefore accessing the string is accessing part of the program's source." \$\endgroup\$
    – ETHproductions
    Aug 11, 2017 at 19:30
  • 1
    \$\begingroup\$ @ETHproductions yup, that's basically what Dennis's answer says \$\endgroup\$
    – Stephen
    Aug 11, 2017 at 19:30
  • 1
    \$\begingroup\$ @ETHproductions the difference is that in accessing a string you are accessing its contents, not its source code. \$\endgroup\$
    – N. Virgo
    Apr 29, 2018 at 12:59

You must log in to answer this question.

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