Viper Availability

Wed Dec 15 13:13:05 EST 1999

Since a couple of people have asked for a copy of Viper,
here is a quick status report.

An early evaluation release of Viperi (the run time test
harnes/interpreter)
has been posted to ftp.python.org/incoming, but has not
been put up in the contrib section. In fact this directory
is now completely empty, and the old contents have been moved
to contrib-Dec09-1999, I do not know why.

I have posted it now to:

	ftp://ftp.cs.usyd.edu.au/jskaller/viper_2_0_a1.tar.gz

Please note this is a very temporary location.
The version there is alpha 1. The '2' in the version
number means this is a Python 2 compatible product. :-)

Please note the LICENSE is for evaluation only: 
this version is free (no cost) but NOT YET public software.
you can redistribute the original tarball, and you can
modify the source, but you cannot redistribute the
modified source, and you cannot use the product
except for evaluation (at the moment).

DON'T BE SURPRISED IF YOU CANNOT BUILD IT OR
IT DOESN'T RUN.
THIS IS SNAPSHOT OF WORK IN PROGRESS, NO CARE HAS BEEN
TAKEN
TO MAKE IT EASY TO BUILD OR INSTALL (at this time).

Send bug reports to 

	mailto:skaller at maxtal.com.au

BINARY: you will need linux2, with 
/usr/local/lib/Python1.5 as the python location.
Please let me know if this works at all!

SOURCE: you will need 
  * Unix or Linux
  * ocaml 2.02 or 2.04 (untested) from caml.inria.fr
  * Python 1.5 installed
  * Gtk 1.2 (probably, 1.2.3)
  * compatible C compiler (gcc/ecgs is fine)
  * whatever Gtk requires
  * gnu readline

IF you have a standard (and recent) Redhat linux system, 
you should already have all of this except ocaml.
Posix threads are required. You must build ocaml
using the -pthread option. Build the Viper sources
by executing the python script 'maker'.
This script requires the optimised versions of
ocaml, but you can edit it if you don't have them.
I have built the package on Solaris, but only by
commenting out all references in the source
to Gtk and readline.

---------------------------

Now for a Viper status report: for version alpha 2,
not yet posted! (watch for announcement here)
[I will wait for feedback from the first release, in case
I have forgotten some files]

The run time test harness (interpreter) Viperi,
now has a thread module, but the interpreter is not
thread safe yet [tracbacks will be jumbled, for example].
Some top level architectural rearrangement is required here.

The GUI module can now do drawing, and the number of widgets
supported is slowly increasing. The eventual aim is to provide
a fully interactive visual debugger [and this will come
quickly, because _I_ need it to test the system :-]

List comprehensions have been added to the grammar, and by the time
you read this article will probably be working (non-lazily).
C style assignment operators are available.
Rational numbers are available.
C style comments are available.
Sensible radix prefixed can be used, and underscores are
permitted in numbers. [O777 style octal is deprecated]
Lexical scoping is standard. positive strides are supported.

Builtin functions have been split into two kinds:
functions, which are dependent only on arguments and
the definition environment, and macros, which may
also access the calling environment: globals(),
dir(), etc, are macros.

What works?
------------

Pystone executes. {Viper is slower than CPython,
but it is getting faster .. ]

Interscript runs, except for the summary tables (which are
invoked by __del__ methods), and the cache:
this is a fairly heavy duty test!

My micky mouse test codes work.

The following CPython builtin modules are implemented:

	sys, strop, pickle, marshal, thread, re,
	posix, errno, struct, time

In addition, traceback is replaced by a Viper module.
[Do NOT expect any python AST modules or other
implementation level services to work]

Other 'pure python' modules work:

	os, string, types, exception

What isn't available?
----------------------
0) probably more than on this list :-)
1) socket is not yet implemented (easy)
2) select is not yet implemented (easy)
3) array is not yet implemented (*** see below)
4) CPython interface (may be much easier than I thought)
5) operator is not implemented (some work)
6) some class methods (__xxxx___) are not implemented
7) __del__ method do not execute 
   [will not be available until ocaml3 is released,
    an earlier hack is possible]
8) re only supports matching, not splitting
   It doesn't support any python extensions either
9) International characters in identifiers are not
   checked for compliance [Any character is accepted]
10) doc strings are ignored
11) Partial evaluation is not yet completed
12) lazy evaluation is not yet completed
13) closures, interpreter objects, and other exotica
    are supported by the run time but cannot be
    accessed by the client programmer
14) continuations and coroutines [this is hard]
15) name binding only works for functions and modules,
    binding for classes and instances has yet to be done
    [name binding converts named lookups in dictionaries
    into indexed lookups into arrays, like CPython
    does with FAST-LOAD for functions]
16) operator

The threading module will probably be re-implemented
using native threading support. This will also
include channels.

Internet wide file opening.
[ie. open('http://www.xxx.org/document.html') should work]

What doesn't work?
------------------

1) Marshal doesn't seem to work with interscript:
   interscript uses it via pickle

2) Quite a lot of functionality of CPython builtin-modules
   is incomplete and untested

----------------------------

*** Arrays. Viper could support the array module easily.
However, there is also a NumPy array subsystem
which has much more functionality.

However, there is a third, interesting, alternative.
Array support in Viper will be intrinsic (i.e. arrays
will be a native type): this is necessary to allow
optimisation, and array processing is one of the areas
that can use optimisation well. I've also got a softspot for
numerical programmers. There is in fact a superior
mechanism for array handling called FISh based on high level 
category theory: this mechanism outperforms all others including 
hand written C and Fortran [work is being done to extend
FISh to support parallel processing by load balancing based on
shape analysis] It is not clear how, or whether,
to integrate FISh arrays with Viper. For example, it is possible
to make 'array of Something' a native type, but it is possible
to do the opposite as well: make EVERYTHING an array.
Also, the FISh front end uses an ML dialect, and it is not
clear how (or whether) to replace this with a Python one. FISh is a
code generator, so it works by partial evaluation with
shape analysis, followed by generating (straight line) code 
which is then compiled and executed: this is much faster than using
a binary library.

-- 
John Skaller, mailto:skaller at maxtal.com.au
10/1 Toxteth Rd Glebe NSW 2037 Australia
homepage: http://www.maxtal.com.au/~skaller
voice: 61-2-9660-0850