Python compiler?

Hannah Schroeter hannah at schlund.de
Mon Apr 23 12:43:57 EDT 2001


Hello!

In article <3ADDD346.9868AA05 at netplus.net>, Luke  <floods at netplus.net> wrote:
>[... type inference ...]

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

That's right. Still it seems to work, at least for Lisp, which can
be quite dynamic, too, and has no mandatory type declarations either.

>[...]

>> >1 dog + 4 legs = octapus

>*hint* (joke)

*g*

>[...]

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

This is clear.

However, passages like (using lexically scoped local variables):
	x = 1
	[... do some number things with x ...]
	x = "abc"
	[... do some nice string work with x ...]
	x = []
	[... push some elements into x, maybe even of different types,
	and peruse the whole thing ...]

can usually be rewritten into:
	x_1 = 1
	[... do some number things with x_1 ...]
	x_2 = "abc"
	[... do some string work with x_2 ...]
	x_3 = []
	[... do some list manipulation with x_3 ...]

which makes type inference a bit easier. You don't necessarily
have to assign just one type to one source code variable name!
One way to do this is to have a soft-typed first intermediate
language in a SSA-like manner, on which you do your type inference
work. As good code usually doesn't use global variables too much,
but rather more local variables and object instance variables/slots,
those strange side effect things on global variables shouldn't hit
performance too much, even if you don't do any type inference on
global variables at all, rather doing complete dynamical checks.

Kind regards,

Hannah.



More information about the Python-list mailing list