A quine is a program that prints its own listing.
Check out David Madore's page on quines at
http://www.eleves.ens.fr:8080/home/madore/computers/quine.html
My immediate reaction was:
Transcript show: (self class sourceCodeAt: thisContext home selector)
[and I was quite proud of myself]
however after reading the section on the fixed-point theorem, I grudgingly
admit that my solution is a cheat. It will not also work unless it is called
from within a method (self is not defined and thisContext home selector will
be #unboundmethod), therefore it should actually display the code required
to compile the method. Gee, what is a program anyhow? Maybe it should also
print out the XML if it is a VW filein?
Still, as tempting as it is to go to the class description to get the code,
in my opinion an interesting solution would use reflection in the same way
that David's scheme version uses eval (e.g. #evaluate:), although there are
probably other even more interesting ways to do this in Smalltalk :-)
As an afterthought, how would this look in CLOS?
--
Cheers,
Steve (steve at wart dot ca ICQ 50919689)
[ replying to comp.lang.lisp only
http://world.std.com/~pitman/pfaq/cross-posting.html ]
"Steve Wart" <·····@deadspam.com> writes:
> A quine is a program that prints its own listing.
>
> Check out David Madore's page on quines at
> http://www.eleves.ens.fr:8080/home/madore/computers/quine.html
>
> My immediate reaction was:
Go to www.deja.com and search for quine in comp.lang.lisp mail over
the last 3 months. I think you'll find some there.
Steve Wart wrote:
>
> A quine is a program that prints its own listing.
>
[...]
>
> Gee, what is a program anyhow? Maybe it should also
> print out the XML if it is a VW filein?
Exactly, I find the distinction between what is a quine and what is a
cheat completely messy.
If we consider the VM to be the interpreter and the image a valid
listing then we could create an image that executes
ObjectMemory snapshotThenQuit: true
on startup.
This could be considered a quine (purists may want to write the snapshot
to StdOut instead of to a disk file). If the image is not stripped
introns make up the bulk of the 'listing'.
Taking this a step further:
If I make a bootable floppy, and the OS it boots copies the boot flop to
a second floppy (perhaps using StdOut in some weird way for the purists)
wouldn't that be a quine?
Worms and viruses could be considered quines.
R
-
copy this sig, it's a quine
"Reinout Heeck" <·····@Desk.org> wrote
>
> Exactly, I find the distinction between what is a quine and what is a
> cheat completely messy.
No it is not. The only issue is whether you talk about quines in
general or solutions to the "write a quine in the language Foo"
problem. Like always, there is an implied context clarifying what is
a correct solution and what is not. What is 3 + 4 -- 7, 11, or 12?
Of course, in languages more advanced than C or Java there are various
interpretations of what exactly is a program, what is its output, and
how to compare them.
Both in Lisp and in Smalltalk, the "legal output" is probably what is
written on a stream-like object, or the value returned from evaluating
the program. Many Lisp quines assume the latter. My Smalltalk quine
assumed the former, but can easily be changed (making it even simpler)
to:
[:s | s, s printString] value: '[:s | s, s printString] value: '
The string it returns is equal to the source string evaluated. Many
Lisp quines return a list, implying that either we do not insist that
input and output are indeed similar objects and a list that prints
like the source string is considered "reasonably equal" to that
source, or the program source is really not the source string but
rather the Lisp reader output.
In Smalltalk, the source is more unambiguosly a string, but we can
argue whether the source of a method is its actual Smalltalk code, or
XML, or chunk format. I personally think the former makes much more
sense since the other two are merely possible external
representations. It is especially so for workspace code.
But this is not the point. The point is that while there is some
freedom in interpreting what is the source and what is the output,
there are a few common sense constraints that help tell cheats from
solutions, with no need to play lawyer about it.
If we have "writing a quine" as a programming problem, it is assumed
that what you produce is a program to be executed in a way commonly
understood as "running some code" in the system you use (so your .sig
is not it), its original form is the source code (so a bootable floppy
is not it), and the essential logic that produces the result is
defined by your program (so saving the image is not it).
Also, since the possibility and principle of quines is
language-independent, it is expected that the solution will use that
principle and not the knowledge of how the source is stored, like
^thisContext method getSource
or simply an object that evaluates to itself and prints the same it is
written in a particular language, such as
nil
''
0
and the like.
In a wider sense, of course, all of the things you list are quines
too. They just won't earn you the grade you want in a CS exam.
There is a very nice anecdote by Rutherford about Niels Bohr's many
ways of measuring the height of a building using a barometer:
http://www.geocities.com/Athens/Acropolis/5148/bohr_storyontests.html
--
Vassili Bykov [|] <·······@parcplace.com>
VisualWorks Engineering
Vassili Bykov wrote:
>
> "Reinout Heeck" <·····@Desk.org> wrote
> >
> > Exactly, I find the distinction between what is a quine and what is a
> > cheat completely messy.
>
[big snip]
>
> If we have "writing a quine" as a programming problem, it is assumed
> that what you produce is a program to be executed in a way commonly
> understood as "running some code" in the system you use (so your .sig
> is not it), its original form is the source code (so a bootable floppy
> is not it), and the essential logic that produces the result is
> defined by your program (so saving the image is not it).
It is above 'commonly' I object to when such matters a quines are
discussed.
I get this nagging feeling that what-is-a-quine cannot be defined
easily, when I start to fantasize a bit I can see all kinds of program
listings in real life. This nagging feeling gets me to distrust the
concept quine entirely. For instance starting an image on a VM is the
standard deployment mechanism of several Smalltalk implementations, it
is 'commonly understood as "running some code" in the system you use'.
Dittto for .sigs (and chainletters, nearly but not quite quines ;-)
> In a wider sense, of course, all of the things you list are quines
> too. They just won't earn you the grade you want in a CS exam.
The 'wider sense' aside with the 'commonly' above illustrates what I
mean. I guess I am missing a definition of what processor/VM the problem
runs on and what the program representations are and which of those are
considered a listing.
In Smalltalk we create programs by pointing clicking and keying, I guess
that in your 'wider sense' a recording of those events is a quine if the
generated program recreated this recording. In this wider sense the GUI
is a language interpreter too, what is it's listing format...
How wide is this sense when it stops being a quine?
> There is a very nice anecdote by Rutherford about Niels Bohr's many
> ways of measuring the height of a building using a barometer:
>
> http://www.geocities.com/Athens/Acropolis/5148/bohr_storyontests.html
:-)
R
-