RFC: Viper: yet another python implementation
mwh21 at cam.ac.uk
Mon Aug 16 00:10:05 CEST 1999
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
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.
> >> 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 ;-).
> >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...
More information about the Python-list