first release of PyPy

[Rocco Moretti]

Kay Schluehr wrote:
> Anton Vredegoor wrote:
> 
> 
>>I'm not involved in PyPy myself but this would seem a logical
>>possibility. To go a step further, if the compiler somehow would know
>>about the shortest machine code sequence which would produce the
>>desired effect then there would be no reason to limit onself to only
>>those relatively inefficent standard code sequences that are inside
>>system dll's.
> 
> 
> Are You shure that this problem is effectively solvable in any
> language? Since You did not precise Your idea I'm not shure whether You
> want to solve the halting-problem in PyPy or not ;)

I'm always amazed at how many people take the intractableness of the 
halting problem as a reason to not even try. Sure, you can't tell if an 
*arbitrary* program halts or not, but there are many where you can. 
(Assuming a perfect Python Interpreter):

c = 5 + 6

halts.

c = 5
while 1:
     c = c + 6

doesn't.

A trip through the Zope internals may be a little harder to decide. But 
one might argue that code that does not give a clear "yes, it halts" is 
poorly written, and should be rewritten to be better behaved.

At any rate, Anton isn't talking about solving the halting problem, but 
is hinting more along the lines of introspecting the code and, for 
example, substituting a bubble sort for a quick sort when the specific 
circumstances determine that it would be quicker. Granted, giving the 
"best" code sequence would be tough to impossible to determine, but a 
"better" code sequence would still make people happy.