On Mon, Jun 17, 2013 at 6:02 AM, Steven D'Aprano <steve+comp.lang.pyt...@pearwood.info> wrote: > On Sun, 16 Jun 2013 12:31:59 -0700, Mark Janssen wrote: >>> The line between compilers >>> and interpreters is quite fuzzy. >> >> It shouldn't be. > > Of course it should be, because that reflects reality.
It's fuzzy AND it seldom even matters. Compare these three text strings: """'aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa'"""" """'a'*64""" """\37\213\b\b*8\276Q\0\3test\0KL\244\f\0\0Ue\264\211@\0\0\0""" """\x78\xda\x4b\x4c\xa4\x0c\0\0\x14\x8d\x18\x41""" Which of these is an interpreted program? I would say: All of them. And they all produce the same output, a series of 64 copies of the letter a. The third one is interpreted by gzip(1) and will create a file called 'test', the fourth is a raw gzip/zlib stream and so is interpreted by (eg) the Python zlib.decompress() function. They're all languages, of a sort. Are they interpreted/compiled versions of that message? Kinda. If you prepend a sfx header to them, do they become compiled and not interpreted? Doubtful. I don't think you could say that this ceases to be interpreted: import zlib print(zlib.decompress( """\x78\xda\x4b\x4c\xa4\x0c\0\0\x14\x8d\x18\x41""" )) Even if you manually imported the code for zlib.decompress, in a way that makes it impossible for your cut-down program to actually compress data (which then breaks the principle quoted from "Programming in Lua"), it's still fairly clearly being interpreted/parsed the exact same way. So it really doesn't matter (so it really doesn't matter (so it really doesn't matter)). [1] ChrisA [1] http://math.boisestate.edu/gas/ruddigore/web_opera/rudd24.html -- http://mail.python.org/mailman/listinfo/python-list