Python compilers?

[Carl Banks]

Heather Coppersmith wrote:
> 
> 
> On Fri, 21 May 2004 03:03:51 GMT,
> Carl Banks <imbosol at aerojockey.invalid> wrote:
> 
>> Paul Rubin wrote:
>>> 
>>> 
>>> Carl Banks <imbosol at aerojockey.invalid> writes:
>>>> > The example above kills any attempt to turn a.bar() into a static
>>>> > procedure call.
>>>> 
>>>> Of course it does--but it's one method.  A compiler, if it's good,
>>>> would only make the optization on methods named "bar", and it could
>>>> probably pare the number of possible classes it could happen to down
>>>> to only a few.
>>> 
>>> How could it possibly know?  The reassignment of a.bar could happen
>>> anytime, anywhere in the code.  Maybe even in an eval.
> 
>> And if it happens anytime, anywhere in the code, the compiler will see
>> it and create more general code.  Or is that impossible?
> 
> The compiler might not see it.  Any function/method/module called while
> a is in scope might change a.bar.  It doesn't even take a perverted
> introspection tool:
> 
>    module foo:
> 
>    import bar
>    class C:
>        pass
>    a = C( )
>    a.bar = 'bar'
>    bar.bar( a )
>    a.bar = a.bar + 'bar' # which 'add' instruction should this compile to?
> 
>    module bar:
> 
>    def bar( x ):
>        x.bar = 3


Compiler builds a big call-tree.  Compiler sees that the object "a" is
passed to a function that might rebind bar.  Compiler thinks to
itself, "better mark C.bar as a dynamic attribute."  Compiler sees
dynamic attirbute and addition.  Compiler generates generic add code.

You could have all kinds of setattrs, evals, and unanalysable data
structures (a la pickle), that could turn the code into a nightmare
that a compiler couldn't do anything with.  But surely, guarding
against all of that, a good enough static compiler can still reduce a
lot of good, maintainable Python code to it's static case.


And, frankly, I still don't see how this is different from Lisp.

(defun foo ()
  (let ((x 1))
    (setq x (bar x))
    (setq x (+ x 1))))

In another package:

(defun bar (x)
  #C(2.0 1.0))

If I recall, + can work on ints, floats, bignums, rationals, and
complex numbers, at least.  What one instruction does + compile to
here?


>> As for eval, well it would be silly to even allow eval in a compiled
>> program; kind of defeats the purpose of compling.  You might let it
>> run in its own namespace so it can only affect certain objects.
> 
> I reiterate my comments regarding type declarations, add new comments
> regarding backwards compatibility, and note that Lisp allows eval in
> compiled code.

It's highly frowned upon cause it interferes with everything it
touches.


-- 
CARL BANKS                      http://www.aerojockey.com/software
"If you believe in yourself, drink your school, stay on drugs, and
don't do milk, you can get work." 
          -- Parody of Mr. T from a Robert Smigel Cartoon