Why not a Python compiler?

[John Nagle]

josephoswald+gg at gmail.com wrote:
> On Feb 5, 4:54 pm, Steven D'Aprano <st... at REMOVE-THIS-
> cybersource.com.au> wrote:
> 
>> Okay, you know how hard it is to create a software JIT compiler for a
>> language as dynamic as Python? It's REALLY HARD, which is why it hasn't
>> already been done[1]. Now you want that done in *hardware*, which is much
>> harder. Who's going to spend the money on R&D?
>>
> 
> To be clear, compiling a language that is dynamic *in the particular
> way Python is designed to be dynamic*, for example, documenting and
> exporting as an API the dictionary lookup mechanism for method
> dispatch, is really hard.
> 
> Compiling languages such as Lisp, which are quite dynamic, and in some
> ways much *more* dynamic than Python, to native machine code has been
> standard practice since the 1970s.
> 
> The issue is how Python, for whatever reason, was designed as a
> language. Not with whether it is dynamic or static.

     Exactly.  Or "when the only tool you have is a hash, everything
looks like a dictionary".  The performance problems of Python stem
from the difficulty of telling whether a hash lookup is really necessary.
The killer is that Python lets you modify the namespaces of all functions,
objects, and modules from the outside.  Given that language spec,
you're stuck with an implementation like CPython where everything really
is a hash internally.

     If the namespaces of objects, functions, and modules could only be
modified from within the object, function, or module, then a compiler
could examine the module and see if there was anything that required
the general late-binding case.  Everything else could then be bound early,
avoiding huge numbers of unnecessary lookups and yielding a considerable
speedup.  It's necessary to provide for the late-binding case to keep
the dynamism of the language, but late-binding everything kills
performance.

     Shed Skin has restrictions like that, but Shed Skin is being
developed by one guy, which isn't much for an optimizing compiler.

				John Nagle