Compiling vs interpreting [was Re: A certainl part of an if() structure never gets executed.]

[Chris Angelico]

On Mon, Jun 17, 2013 at 6:02 AM, Steven D'Aprano
<steve+comp.lang.python at 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