Home Original page

Python compiler?

Luke floods at netplus.net
Wed Apr 18 13:47:50 EDT 2001 
> 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.

Sure you can find out the possible types for each variable, but types that change
conditionally upon runtime factors will add ambiguity and slow things down.

>
> >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 = {}
>
> 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.
>
> 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

*hint* (joke)

>
> >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.

Ach... You're reading too much into the example.  You must have been a lawyer in
another life.  The point was that x could be different things, not just code that
assigns pointers.  So no, it wasn't a good example for what I was trying to say.
More information about the Python-list mailing list