# Is a quine that reads a function's source a cheating quine?

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?

• – Stephen Aug 8 '17 at 17:51
• 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. – ETHproductions Aug 18 '17 at 21:21
• 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. – Nathaniel Apr 29 '18 at 13:12
• @Nathaniel What can you say against "the "a()" encodes the a() at the end"? – user202729 May 2 '18 at 12:47
• @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. – Nathaniel May 2 '18 at 13:39
• @dylnan I unaccepted, will leave it unanswered for now – Stephen Jul 26 '18 at 20:23

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

• 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 – Conor O'Brien Aug 8 '17 at 19:05
• 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. – dzaima Aug 8 '17 at 19:19
• @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. – Dennis Aug 8 '17 at 19:23
• @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. – dzaima Aug 8 '17 at 19:32
• So, f=_=>"f="+f is now a valid JS quine? Sweet! – Shaggy Aug 9 '17 at 10:46
• @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. – Stephen Aug 9 '17 at 14:07
• 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 :( – Shaggy Aug 10 '17 at 10:54
• @Shaggy well everybody was wrong :P there are a lot of deleted JS quines like this – Stephen Aug 11 '17 at 19:31
• This seems to allow def printFunc(){return str(printFunc)} (assuming str returns the string representation of the function). Am I correct? – Nathan Merrill Aug 17 '17 at 19:39
• @NathanMerrill I believe most quine problems require printing of the source, not just a function return. – Stephen Aug 18 '17 at 14:44
• 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. – Nathaniel Apr 27 '18 at 14:24
• 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. – Nathaniel Apr 27 '18 at 14:28
• 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. – Nathaniel Apr 27 '18 at 14:32

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

• So just to clarify, the CJam quine {"_~"}_~ is cheating by this definition? – ETHproductions Aug 18 '17 at 2:15
• @ETHproductions Yes, I claim it is cheating. – Neil Aug 18 '17 at 7:58
• 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). – ETHproductions Aug 18 '17 at 21:03
• @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.) – Neil Aug 18 '17 at 23:18
• 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. – ETHproductions Aug 19 '17 at 0:16
• 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. – ETHproductions Aug 19 '17 at 0:21
• @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 – Stephen Aug 19 '17 at 2:23
• @StepHen That's why I said "if functions are allowed as answers to the challenge" – ETHproductions Aug 19 '17 at 2:26
• @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. – Neil May 3 '18 at 0:07

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

• 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." – ETHproductions Aug 11 '17 at 19:30
• @ETHproductions yup, that's basically what Dennis's answer says – Stephen Aug 11 '17 at 19:30
• @ETHproductions the difference is that in accessing a string you are accessing its contents, not its source code. – Nathaniel Apr 29 '18 at 12:59