<div dir="ltr">I wonder whether a more restricted form of Python would not be acceptable in situations where speed is critical. I mean, instead of cl-python, that tries to mimic the semantic of Python closely, the Lisp community could write a compiler for the subset of Python that the majority of people really use. This subset of Python would share the semantic of Lisp.<div>
<br></div><div>I believe that the strategy of specialised operators adopted in Scheme and Racket could be useful for Python too. I mean, operators like fx+, fl+, fl*, etc could help the compiler infer the type of the operands. I am not thinking about Python at large, but that brand of Python that Lisp programmers like so much to implement: cl-python, bigpy, lambda-py, etc. A Lisp to Python translator could be very useful for Lisp programers that need to port a small Python library to Lisp. Of course, translation to Lisp is meaningless if the result proves to be as slow as Python.</div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">2014-05-14 10:40 GMT-03:00 Konrad Hinsen <span dir="ltr"><<a href="mailto:konrad.hinsen@fastmail.net" target="_blank">konrad.hinsen@fastmail.net</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">Eduardo Costa writes:<br>
<br>
> Is there anything in the semantic of Python that makes it much more difficult to<br>
> implement a Python compiler than a Racket compiler?<br>
<br>
</div>Python is much more dynamic than Racket. As an illustration, look at a simple<br>
operation: addition. In Racket,<br>
<br>
(+ a b)<br>
<br>
requires dispatching on the types of a and, from a finite (and small)<br>
list of admitted candidates (fixnum, flonum, ...). Anything else is an error.<br>
<br>
In Python,<br>
<br>
a + b<br>
<br>
is just syntactic sugar for<br>
<br>
a.__add__(b)<br>
<br>
which means (1) Look up the type of a, (2) look up '__add__' in the<br>
method dictionary of that type and its supertypes, (3) if not found,<br>
look up '__radd__' in the method dictionary of the type of b, (4) call<br>
the resulting method. None of the intermediate lookups can be cached<br>
because everything might be different the next time that operation is<br>
executed: a and b can have different types, and the definition of<br>
__add__ for the types of a and b can have changed.<br>
<br>
Konrad.<br>
____________________<br>
Racket Users list:<br>
<a href="http://lists.racket-lang.org/users" target="_blank">http://lists.racket-lang.org/users</a><br>
</blockquote></div><br></div>