Steven D'Aprano wrote: > On Sun, 19 Feb 2006 13:02:16 -0800, Paul Boddie wrote: > > >> Bruno Desthuilliers <[EMAIL PROTECTED]> writes: > >> > > >> > Ok, then what do you think happens to 'machine' code ? > >> > > >> > "interpreted" usually means "no compilation, all parsing etc > >> > redone at each execution", which is not the case with a > >> > bytecode/vm based implementation. > > > > Such criteria sound more like those which would distinguish interactive > > languages from others. > > How can that be? Python is interactive, and yet it has a bytecode/vm > implementation.
The criteria were "no compilation, all parsing etc redone at each execution": things which would possibly describe features of a language where much use is made of an interactive mode, and where there wouldn't be many advantages in generating instructions in another form for later execution. Not that this applies to Python, since it does compile source code to bytecode instructions as we all know, and the only re-parsing occurs in well-defined circumstances, but there have been other "dare I say scripting?" languages whose execution models have apparently involved ASTs instead of virtual machine instruction sets. [...] > > And it's even better to think about the nature of the machine... > > Is it? Why? Do you particularly know what happens when your machine code > hits the CPU? In general, yes: it's interpreted by a virtual machine implementation in hardware. But this is where the nature of the machine is important, as I originally wrote, since you don't want highly complicated instructions implemented in hardware for a variety of well-understood reasons. [...] > Let's be frank: "interpreted language" has negative connotations which may > have been valid in the 1960s and perhaps even the 1970s, but are no longer > automatically valid. Nevertheless, those connotations stick around, > generally amongst the less knowledgeable. That hurts Python's commercial > success, and Python's commercial success is vital for anyone who wishes to > get paid to program in Python. I think we're mostly in agreement here. My point was, as usual, tangential: there is a certain class of instructions conveniently or economically implementable in hardware; CPython's runtime also has instructions more complicated than those. Consequently, when people used to speculate about Python CPUs and other magical devices that would make Python run much faster (see [1] for more recent material which doesn't specifically do so, although I believe the speaker made references to such devices; see [2] for an old mailing list thread), one has to accept that there are certain constraints that have a severe effect on whether such devices are viable or not. If some people want to classify runtime environments on this basis then I don't have a problem with that, provided that they are honest about it and put things like the Java VM in the same category as CPython. Paul [1] http://www.python-in-business.org/ep2005/talk.chtml?talk=2116&track=692 [2] http://mail.python.org/pipermail/python-list/1999-June/thread.html#4543 -- http://mail.python.org/mailman/listinfo/python-list