From: skaller@maxtal.com.au (John (Max) Skaller)
Subject: RFC: Viper:  yet another python implementation
Date: Tue, 10 Aug 1999 20:37:40 GMT

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.

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. 

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
	3) None is a keyword.
	4) range is a keyword

	5) What restrictions can you live with?

Extensions:
	1) full slicing semantics
	2) optional values in dictionaries (Defaults to None)
	3) 'in' applies to dictionaries 'as if a sequence of keys were used'
	4) lexically scoped functions (including lambdas)
	5) optionally typed function parameters

	6) what do you want?

Optimisations:
	By using type inference on pre-imported modules,
it is possible to perform considerable optimisations.
For example, functions can be inlined, and variables
whose types are known can be replaced by native
types. This will generally work best with Viperc, the compiler.
The optimisations will hopefully include using
a mutable string (internally) so that

	x = x + "at the end"

can be changed into an append provided
'x' is not aliased.

	In addition, even in the interpreter,
various special case constructions can be significantly
optimised. For example:

	for i in range(1,10): print i

is controlled by a native for loop, no sequence
object is constructed, not even a lazy one.

	Generally, compiler optimisations
will go hand in hand with restrictions -- to optimise
something, information is required, and that will
require giving up some dynamism.

	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,
and it may involve other restrictions
(such as not  changing any module bindings
after loading).


John Max Skaller                ph:61-2-96600850              
mailto:skaller@maxtal.com.au       10/1 Toxteth Rd 
http://www.maxtal.com.au/~skaller  Glebe 2037 NSW AUSTRALIA