RFC: Viper: yet another python implementation

[Michael Hudson]

skaller at maxtal.com.au (John (Max) Skaller) writes:
> On 11 Aug 1999 18:23:06 +0100, Michael Hudson <mwh21 at cam.ac.uk> wrote:
> >I'm interested (do you have any code yet?
> 
> 	Not for the compiler: I'm implementing
> the interpreter first. [I have done some work on the
> type inference algorithm, to make sure it is
> feasible]

Let me rephrase that a little: do you have any code that I can look
at/play with/beat on/improve (maybe)? Actually working/complete code
is not expected or desired, I'm just nosey.

> >I presume fiddling with sys.exc_traceback.f_back.f_locals is out?
> 
> 	At present sys.exc_info() will return a tuple in which
> the third element is a traceback object. At present, that
> traceback object doesn't match the Python one --
> it just has a filename and line number in it, to allow the
> traceback to be printed.

I feel I ought to point out that I'm not particularly desperate to
retain the ability to perform this particular stunt, I was just trying
to get a feel for the limitations you were talking about.

> >But can foo then have a method set_bar? I guess that would be easier
> >to cope with for the analyser.
> 
> 	Yes. It is OK to mutate objects, as opposed
> to rebinding variables: mutation has to be supported.
> You may think these things are equivalent. Indeed,
> they are in interpreted python. 

I'd dispute that, but never mind.

> However, the restriction leads to a performance gain; without some
> restrictions, compiled python will not execute faster than the
> bytecode interpreter.

Quite.

> >> 	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).
> 
> 	OK. I would like to do what Guido has done in the
> optimisation of functions [fast lookup for statically known variables,
> plus a dictionary to support others]: provide an optimised structure
> where possible, and then provide a dynamic one
> for the other cases.  That is, the ideal would be to provide
> a 'fallback' to the interpreter.

vtables might be nice (i.e. attribute accesses don't always go through
a dictionary lookup). Bigger win for compiled code, I suspect.

You could only vtable-ize the methods/data members that static
analysis found were never assigned to in code. This suggests another
restriction for exec.

[snipped dictionary extensions that I still don't see the need for but
then again if I don't like them I can just ignore them]
 
> >> 	5) optionally typed function parameters
> >
> >Out of curiosity, what syntax do use for this? 
> 
> 	My first idea was the obvious:
> 
> 	def f(a:int): ..
> 
> or perhaps
> 
> 	def f(a: IntType): ...
> 
> and the interpreter semantics would be 
> 
> 	if type(a) is not InType: raise TypeError, "Int expected for arg1 of f"

Fair enough; it might be nice (& probably very easy) to hack a CPython
that accepted but ignored type declarations of this sort.
 
> However, in the compiled version, the semantic might be to generate
> a compiler error: that is, the following might not work:
> 
> 	try: f(1.0)
> 	except TypeError: pass # just skip the call

I'd say if you coded like that you deserved to lose anyway. Might
become a bigger problem in more complex cases, of course.

> >I presume if a
> >parameter is typed as `Foo' then a value of type `Bar' where Bar
> >derives from Foo is allowable.
> 
> 	I guess that would make sense (the extension isn't
> implemented yet -- not a lot of point appealing for comments
> _after_ implementing the extension, only to find someone
> has a better idea)

I think it would be a hanging offense for anything that called itself
OO to not allow a instance of a derived class to be substituted for
that of a base class.

> >> 	6) what do you want?
> >
> >Can you derive from basic types? That might make some stuff harder.
> 
> 	Not at present. Can you give an example where
> it is useful? [It can be made to work I think: is it useful?]

It's more neat than useful, as far as I can see. But I'll have to
learn more ml, Haskell, smalltalk, Eiffel and lisp/clos before I can
comment properly on type issues, I think (I am actually moderately
serious about learning all the above languages - doing Haskell, Eiffel
and ANSI common lisp at the moment).

> >> 	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.
> 
> 	No. I cannot do that because the program
> that I want to compile, interscript, uses exec,
> and depends on it to execute client script.
> This is the major feature of interscript, so exec
> has to work (at least with restrictions).

I see; I guess what you're saying is that exec-ed code can't muck with
it's calling environment too much. I'd have thought this would be a
feature for interscript, otherwise malicious documents could seriously
injure the environment.

> 	That means the compiled code has to
> contain a full run time system (unless it can be
> detected that it isn't required).

Lisp manages to have a very clean interaction between compiled and
interpreted code: you type (compile 'f) and hopefully the only
noticeable difference is that `f' goes quicker. Mind you lisp has had
man-millennia of time from very very clever people poured into it, so
that might be aiming a bit high ;-).

[snip]

> >Mind you, the whole thing sounds sooo hard, that
> >anythong that makes it easier is good.
> 
> 	The things that turn out to be hard are
> often surprising. 

That's always the way. I think a large part of programming experience
(of which I don't have a vast amount) is spotting the problems and
being able to come up with top-level designs that are compatible with
further growth. Hard problems.

> For example, right now I having
> major problems with something that sounds trivial:
> getting the interpreter to set the line number
> so that a traceback can print out as it does in Python.
> 
> 	That sounds easy, but the LR grammar I'm
> using is not well adapted to it -- NEWLINE tokens
> come after statements, instead of before them,
> where the line number is needed.

Not something I've done, but it's always struck me that
compilers/parsers that only have to deal with good code must be far
easier to right...

Regards,
Michael