RFC: Viper: yet another python implementation

[Michael Hudson]

skaller at maxtal.com.au (John (Max) Skaller) writes:

> This is a request for comments on Viper, Yet Another implementation
> of Python. I'm building Viperi, the interpreter,  and I'm interested in
> comments on three issues:
> 
> 	1) compatability with Python
> 	2) Extensions
> 	3) Optimisation
> 
> Viperi is being built as a prelude to implementation of an optimising
> compiler, Viperc. Unlike previous attempts at a compiler, Viperc will do
> type inference, inlining, and special case analysis,
> in an attempt to optimise generated code.

I think JPython does some global analysis; not heard anything on that
front for a while though.

I'm interested (do you have any code yet?) but I have a few questions:

> The interpreter aims to be compatible with 'pure python':
> python not using external C modules, and not fiddling
> implementation details too much. Some of the fiddles
> will work, and some will not. 

I presume fiddling with sys.exc_traceback.f_back.f_locals is out?

> Compatibility:
> 	1) exceptions: both string and class exceptions are supported,
> 	the class exceptions are client defined in exceptions.py
> 
> 	2) rebinding module variables after importing is not permitted

Does this mean the following is illegal:

import foo
foo.bar = 1

But can foo then have a method set_bar? I guess that would be easier
to cope with for the analyser.

> 	3) None is a keyword.
> 	4) range is a keyword

What about other builtins? Can't your static analysis find rebindings
of builtin names (including range) rather easily? - particularly as
the don't happen very often.

> 	5) What restrictions can you live with?

One thiung I occasionally find very handy is the ability to assign
methods to classes (or more usually within classes).

> Extensions:
> 	1) full slicing semantics

Cool.

> 	2) optional values in dictionaries (Defaults to None)

Now this one I don't get; do you mean dict[] has dict.get like
semantics?

> 	3) 'in' applies to dictionaries 'as if a sequence of keys were used'

Seems unecessary to me. Maybe that's just me.

> 	4) lexically scoped functions (including lambdas)

Cool.

> 	5) optionally typed function parameters

Out of curiosity, what syntax do use for this? I presume if a
parameter is typed as `Foo' then a value of type `Bar' where Bar
derives from Foo is allowable.

> 	6) what do you want?

Can you derive from basic types? That might make some stuff harder.

[snip]
> 
> 	It is difficult to optimise individual
> modules. It is a different story to optimise
> a whole program, where _every_ call
> to a function can be traced. Of course,
> this may involve restricting what 'exec' can do,

Like banning it entirely, I suspect.

> and it may involve other restrictions
> (such as not  changing any module bindings
> after loading).

Is that really that much of an issue? I'd have thought that they'd be
fairly easy to spot. Mind you, the whole thing sounds sooo hard, that
anythong that makes it easier is good.

Good luck! (I think you may need it)

Michael