Note: In this Meta question, it was determined that the correct thing to do if you think an established consensus has become outdated is to post a new question, even if the question would otherwise be considered a duplicate.
Our current rule for defining a "proper quine" is as follows:
It must be possible to identify a section of the program which encodes a different part of the program. ("Different" meaning that the two parts appear in different positions.)
Furthermore, a quine must not access its own source, directly or indirectly.
However, in the time since the precedent was set, several counterexamples have turned up that bring this consensus into question.
Known issues with the current definition
Two literals which each print the other
A few languages (mostly stack-based languages) naturally process things at the right hand end of the program first. This means that if you write two literals into a program, you'll get the literals output in reverse order. This is something of an end-run around the aim to prevent a quine consisting only of literals; it's also inconsistent (the same rule would disallow the comparable solution in a language that prints literals from left to right).
A second issue with this is that it can lead to some absurd conclusions. Suppose the task were instead to write an order-2 cyclic quine (i.e. two programs that each output the other), but the two programs were allowed to be identical. You'd assume that any proper quine would also be a correct answer to this question, but with our current definition, quines like the above are no longer valid 2-cyclic quines (but would be valid 3-cyclic quines). A good proper quine definition would ideally avoid this sort of issue.
Literals which print themselves plus a no-op
05AB1E, 2 bytes
PowerShell, 2 bytes
In both PowerShell and 05AB1E, an empty program prints nothing, and an integer prints itself followed by a newline. Additionally, a final newline is a no-op and has no effect; as a result, if we append the no-op to the literal, we get a proper quine by the current definition (because it's clear that the integer encodes the newline, rather than the newline encoding itself). On the other hand, it very much seems as though this sort of answer isn't in the spirit of proper quine competitions. (Interestingly, this loophole is one that people haven't widely tried to exploit, perhaps out of a sense of fair play.) It seems like a good proper quine definition would disallow this sort of thing.
Programs which explicitly print output that would have been printed implicitly
This has only come up once naturally, in 7, and it requires the program to be expressed in binary (
E7); thus the situation's somewhat hard to get your head around. Here's the description I gave in the comments of the old quine definition challenge:
A similar situation in more familiar syntax: suppose I have a programming language which prints every command as it's executed, with no newline, but always ensures that output has a final newline if it's missing one; is
print "\n"a quine?
The conclusion we came up with on discussion of this at the time is that our current definition of a proper quine doesn't handle this situation at all, not giving a clear answer on whether or not this is a proper quine. We'd want our definitions to handle all cases.
Uncertainty about what characters make up a literal
(No TIO link, because this doesn't work on FBBI, the interpreter TIO uses.)
In this quine, the final 7 characters each encode themselves, and the first is a space. The space is produced from a string literal defined using
k', and the string literal wraps around the program. String literals in Befunge-98 (at least in
cfunge) treat any wrap around the program as a single space character, and merge any string of consecutive whitespace into a single space. So is the space at the start of the program produced from the literal space, or from the wrap? Removing either the space, or the wrap, would still leave a space in the string. The current quine definition seems to assume that it's always possible to uniquely identify what characters in a program are responsible for producing a particular piece of data, but that's not always the case.
Kimian (error) quines
See this question for a ton of examples of error quines. The basic problem here is that the error message being printed comes mostly from the language implementation, rather than from anything in the program. So what part of the program encodes it? Applying our current proper quine definition in this sort of situation is hard, and it's unclear whether error quines count by default.
Note that any new definition will have to take into account the fact that error messages often echo part of the source; this complicates attempts to determine whether the quine is literal-only (e.g. see the error quine at the end of this post; the first line is clearly responsible for determining the content of the second, but it isn't exactly a string literal), and also raises questions as to whether the program is reading its own source.
Finally, there's a defensible opinion that some people hold error quines are never proper quines, regardless of how they function. Clarity on this point would be useful.
Generalized quines which rearrange parts of the output
This problem was inspired by this challenge, which asks programs to output an anagram of themselves. In this sort of problem, how do you tell which parts of the input correspond to which parts of the output? It's possible to tell if all the characters of the program are unique, but if there are duplicates, you can't necessarily tell which character of the program was being printed by any particular character of the output.
Situations which are only informally defined at present
See, for example, the current Cubix recordholder. The basic idea is to exploit a language where the source code has unusual topology (like a cube or a torus), and wrap a string literal so that it goes entirely around the program, allowing the program to effectively read its own source code.
But wait, I thought a proper quine wasn't allowed to access its own source, even indirectly? However, topological quines are typically accepted on PPCG. So the proper quine definition could really use clarifying to be clear as to whether or not this sort of case is allowed.
Reading the memory that contains your program
When a program runs, it typically loads itself into memory as a memory image. Languages that use a parserless interpreter have that image identical to the program's source; this most commonly includes machine code and Befunge one-liners. Here's an example (the question is basically "write code that compiles into a quine"; thus, the compiled output of the linked answer is a quine, even though the answer itself is not a quine).
Some languages also give access to this memory, e.g. Befunge's
g instruction (or in machine code, the fact that the code segment is addressable). This is commonly used in machine code for defining the equivalent of a string literal (in fact, it's what string literals compile into). Modern OSes tend to have a separate "read-only data" section for this sort of constant, but using it is just a guideline, rather than a rule, and you can actually mix all the code and data together if you want to.
So the question is, under what circumstances can this sort of memory-reading instruction be used in a proper quine? The current consensus appears to be "you can read any part of your program image that isn't actually executed", but that doesn't seem to be stated anywhere in the quine definition.
Situations which our current definition handles, but new definitions need to take into account
One of the two most common cheats (other than reading your source from disk), that we'd want to disallow in a quine definition, is the literal-only quine: write a literal (typically a number, although some languages allow almost anything in literals), and have it implicitly printed. This answer contains a listing of many languages which do this (together with a few that don't).
Literal-only quines are considered improper, and in fact much of the reason we have a proper quine definition is to try to exclude them in an unambiguous way.
Jelly, 6 bytes
a= "print('a=',repr(a),';eval(a)#r3TQJ')" ;eval(a)#r3TQJ
The basic idea behind an eval quine is to write basically the entire program inside a string literal, then evaluate the string literal, giving the program an effective method of seeing most of its own source. Unlike most traditional quines, you therefore have to write most of the program only once, rather than the normal twice. We currently accept this sort of thing as a proper quine. However, disallowing it is also a defensible opinion (that is seen every now and then), because the same characters are used as both code or data. A good proper quine definition needs to come to an opinion on whether or not we want to accept this sort of thing.
It should be noted that banning
eval and friends outright is probably a bad idea, because some languages (e.g. Underload, Muriel) require
eval-alikes to do any nontrivial control flow.
In some languages, e.g. 7, the initial content of memory is taken from the program itself, and the interpreter proceeds via evaluating copies of that memory. So, for example, something which (in more normal syntax) could be written as
print; exit; anything would be, effectively, an eval quine.
This sort of program is unambiguously disallowed under the current quine definition; in general, though, it falls into a grey area both in terms of being literal-only, and in terms of reading its own source. (The current definition treats it like a literal-only program, although it's clearly a bit different in nature from those.) It should be noted that unlike a typical literal-only quine, this sort of program is a universal quine constructor; you can add extra code to it in order to produce a generalised quine that outputs any function of its source code.
How can we improve, or outright replace, our current proper quine definition so that it can handle all these edge cases with respect to what should count as a quine?
Note that it seems likely that most proposed definitions will use different rules to disallow literal-only improper quines and source-code-reading improper quines, via some definition of "literal-only" and some definition of "source-code-reading". This means that the best possible solution may involve mixing parts of different quine definitions, meaning that they should likely be posted in different posts; in other words, we're voting on parts of a quine definition here, rather than on complete definitions.