Viper: yet another python implementation

[John Max Skaller]

On Thu, 12 Aug 1999 00:15:12 +0200, "Dirk-Ulrich Heise" <hei at adtranzsig.de> wrote:

>Bruce Dodson schrieb in Nachricht ...
>>Ni!  I don't see the point of creating a variant of python that aims to be
>>more efficient, but does so at the cost of taking away Python's most
>>powerful optimization mechanism: external C modules.

	The answer is simple: external C modules
may be the most powerful optimisation mechanism _at present_,
but with a compiler, that will no longer be true.

	'foreign' modules will still be needed to add functionality
that cannot be implemented in Python, such as access to OS services.
However, if pure python can be compiled to efficient code,
there is no need to hassle with C modules just to get better performance.

>Here, i agree with Bruce.
>At the moment, it's common practice to accelerate a Python
>program that's too slow by moving parts of it into homebrew
>extension modules. Taking away this option would maybe
>invalidate Viper as a means of optimization. 

	Why? If you _kept_ the original python
source from which the C code is derived, then you
could just throw out the C code and use the Python code
again. If you didn't, you are in for trouble when the Python
C API is upgraded or changed, or you decide to mode
to JPython.

>It would be okay
>with me, though, if you allow a different kind of extension
>modules (a different interface to the extension module)-
>if ViperC creates C code, i don't see a big problem with
>that.

	There will be at least one, or perhaps more,
ways of adding extensions, but the primary purpose of this
will be

	a) for compatibility (not efficiency)
	b) for adding new functionality that pure python cannot support

There is a secondary purpose in allowing foreign language extensions
for efficiency, when Python does not have the constructions to
allow the compiler to optimise the code (or it is simply too hard to
do so).

	In these cases, modifying the compiler, or adding
extensions to the language, may prove a better option,
since it retains the 'pure language' approach. In these
cases backwards compatability is lost, but it is also
true whenever you write a C module, you are bound to
a particular C API and lose compatibility with JPython
and probably CPython 1.6 and 2.0 and 1.4, etc.

>In this case, i disagree with Bruce. Implementing a subset
>of Pythons semantic possibilities and keeping the same syntax makes
>sense in real life. Just try to write your production code in a less
>wild fashion than usually, not changing bindings all over, and you'd have
>a comfortable way of getting at more speed without rewriting as
>much stuff as if you had to port it to C.

	Yes, that is the basic premise: you can use Python's
nice syntax, and get _efficient_ code, and if you are careful,
it will run on CPython, JPython, and Viper. 

	This is the kind of code that one should aim for
most of the time anyhow: if you really do use nasty tricks,
at least the use should be isolated, and the dependence
reasonably transparent.

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