<br><br><div><span class="gmail_quote">On 12/12/06, <b class="gmail_sendername">Kay Schluehr</b> <<a href="mailto:kay.schluehr@gmx.net">kay.schluehr@gmx.net</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Dear Python developers,<br><br>while the JVM is opened to support dynamically typed languages [1] I<br>wonder if the CPyVM could not show more openness to statically typed<br>languages? Hereby I don't think that much about arbitrary languages for
<br>the CPyVM but sublanguages like RPython which are "static enough" to be<br>compilable into extension modules [2].<br><br>However creating C extension modules from Python code is not really the<br>standard way I do think Python source should be handled. Instead I think
<br>about a more direct VM support like the JVM does, that provides opcodes<br>like iload, fstore etc. Besides this I don't expect one canonical<br>approach for these type information to be feeded into the CPyVM. There<br>
are type inferencer like rtyper for PyPy, Psycos continous bytecode<br>monitoring and also other approaches are possible that use type<br>feedback. Finally optional type declarations are also an issue; however<br>I would like to see language design discussions being separated ( ->
<br>Python 3000 ) and focus on general APIs for compiler extensions / plugs<br>that deal with type information ( the architecture ) and VM<br>implementation issues.<br><br>Thanks, Kay<br><br>[1] <a href="http://jcp.org/en/jsr/detail?id=292">
http://jcp.org/en/jsr/detail?id=292</a><br>[2] <a href="http://codespeak.net/pypy/dist/pypy/doc/extcompiler.html">http://codespeak.net/pypy/dist/pypy/doc/extcompiler.html</a></blockquote><div><br>The Python VM is not designed to be general-purpose, period. Nor does anyone on python-dev, to my knowledge, have any interest in putting the time and energy into making it general. I am quite happy with letting the Parrot folk handle this goal. This means that the maintenance cost of adding more opcodes is not worth it.
<br><br>But a bigger issue with me is the performance hit. Every opcode will make the eval loop larger. And it is known that the eval loop is rather finicky in terms of size and performance. While no hard testing has been done, it has been assumed we have accidentally hit the sweet spot in terms of CPU cache size.
<br><br>An important thing to keep in mind when comparing Python's VM to Java's is that Java works (somewhat) for dynamic languages because people are motivated enough to shoehorn languages into it by just assuming everything is just an object and tossing out the type checking inherent to Java. But Java has not, to my knowledge, grown any great features yet to make dynamic languages work better. I know about JSR 292, but that is not in yet and adding just one opcode is not that expensive to the JVM. But compare the cost of adding a slew of typed opcodes to Python compared to the JVM adding just one is not really equal.
<br><br>In other words, I wouldn't count on this ever happening. =) The best you could do is try to propose some direct mechanism for adding support to the eval loop to dispatch to some function for unrecognized opcodes, but I wouldn't count on that being accepted either.
<br><br>-Brett<br></div></div>