Python compiler?

[Hannah Schroeter]

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

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

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