Python compiler?

[Ken Seehof]

From: "Hannah Schroeter" <hannah at schlund.de> wrote:
> Hello!
>
> In article <3ADCF03C.EC1EF1B8 at netplus.net>, Luke  <floods at netplus.net>
wrote:
> >To compile a language, you need to know types explicitly so memory
'boundaries'
> >are known.  When you can say x = 1; x = []; x = {} that poses a major
problem.
> >There is no 1 type.
>
> This isn't really a problem. Of course, if no good (strong enough) types
> can be deduced, the compiled code will not be as efficient as code typed
> with strict enough types, however, there will often still be much to
> gain.
>
> >I think there is a tool called freeze (my memory is very sketchy) that
will
> >make a self contained exe.
>
> >I know! Guido can add typing to the language!  It'll be great.
> >list x = []; dict y = {}

wonderful :-)

> Isn't really needed. Data flow analysis, renaming of separate lifeness
> spans, then type inference often gains much without changing a
> source language. And where no unique type can be deduced, you must compile
> some dynamic dispatch.

I keep hearing that kind of thing.  Maybe I'm missing something but it seems
like a compiler would need -reliable- type information to make any
meaningful
use of type inference.  Because python is not a functional language (and I'm
definitely not suggesting that it should be) reliable type inference would
seem
to be impossible.

A good type inference engine would probably get the right answer 98% of
the time, but would be -certain- of the correct answer maybe 2% of the time.

from zaphod import Z
z = Z()
x = 5
print z
x = x+1

Ok, so what is the type of x now?  We simply don't know since that would
require deep path analysys of the zaphod module in order to confirm that
Z.__str__ doesn't modify 'x' in the local namespace.  Of course this is an
absurd example, but the point is there probably is no way for a compiler to
know algorithmically that this is an absurd example.  Almost every line of
code in python involves an arbitrary function call that may have unknown
side effects.  The only kind of statement I can think of that doesn't
instantly
dissolve reliable analysis is the simple assignment statement (not member or
indexed assignment), and there is probably some clever hack I'm not
thinking of that would ruin that too.

One could attempt to make use of unreliable type inference by adding type
checking to conditionally execute optimized code when the object happens
to have the correct type, but I think you would end up with a type check
on almost every line.  Hardly what I'd call optimization.

> Just have a look at good Lisp implementations (which has optional
> type declarations, but you can compile code w/o declarations too).
>
> Or functional programming languages with e.g. Hindley-Milner style
> type inference, like ML or Haskell.
>
> >1 dog + 4 legs = octapus
>
> >Luke
>
> Kind regards,
>
> Hannah.
>
> PS: Your example above isn't too good, as a good compiler will see
>   x = 1
>   x = []
>   x = {}
> and deduce: the first two assignments have no side effects except
> writing to x. However that side effect is cancelled through the third
> assignment, so transform this to
>   x = {}
> And now, x has a better inferred type. W/o the transformation, the
> type would be (e.g. in Lisp-like notation):
>   (declare (type (or number list tuple) x))
> We DO for example deduce that symbols (except for nil, which stands
> for the empty list) or hash tables are not stored in x.
> --
> http://mail.python.org/mailman/listinfo/python-list
>