How is Python designed?

Limin Fu fulimin_yuan at
Sat Dec 4 21:12:02 CET 2004


Probably you didn't understand well what I meant or
maybe I didn't express clearly what I meant. So I
think I need to spend more words to make it clear.

First, there is no abstract syntax tree generated for
the whole program, except for arithmetic
expression(even for this, it is slightly different
from what you said, I will come back to this point).
The Yuan (the name of the interpreter I designed)
interpreter first scans the source script, when it see
a pattern, for example "if(a>1)", it generates a
phrase object containing the arithmetic expression and
the ID (it is determined after all phrase objects are
created) of other two phrase objects. This phrase
object has a member method "execute()", whose
execution will return one of the IDs depending on the
value of "a>1". Then the next phrase object with that
ID is executed, and so on. I don't know how is the AST
for a whole program, I think it should be more
complicated than this.

Then about arithmetic expression, indeed, it is
represented as tree. But in Yuan each node contains
all the information it need for evaluation. For
example, the leaves contains either a variable or a
constant value or a function call, and other nodes
contains the operators. So far it is more or less the
same as what you mentioned. But the evaluation is
performed on this tree directly with deep first
search, which is different from the two methods you
mentioned. The first one you mentioned is the same as
my first implementation, which results an unefficient
recursive function call. The second is the standard
way of evaluating arithmetic expressions. I guess I am
not the first one to evaluate arithmetic expression by
deep-first search on the tree (I would be surprised if
I am). Any way it is enough efficient.

Your further comments and discussion are welcome, I'm
not that type who is afraid of negative opinions :)
Any way I will continue to improve that interpreter,
it's an interesting thing for me.



> I'd say that's pretty much standard interpreter
> technique - an expression
> like this:
> foo = a + b * c
> is translated and reduced to an abstract-syntax-tree
> something like this:
> Assignment("foo", BinaryOp("+", Get("a"),
> BinaryOp("*", Get("b"),
> Get("c"))))
> Then on Assignment one can invoke eval(), and get
> the result. Assignment
> will invoke eval on its children, which in turn will
> do that for their
> operands, until something can be computed. The
> result is returned.
> By using an emulated stack or register-machine, you
> can flatten that to
> something like this:
> push Get("c")
> push Get("b")
> push BinaryOp("*")
> push Get("a")
> push BinaryOp("+")
> pop  Assignment("foo")
> This is of course very makeshift - but you'll get
> the idea.
> This doesn't mean I want to discourage you - on the
> contraire. Developing
> your own language is highly educating, and I
> personally love it when I
> "invent" something and then later find out that
> people much cleverer than
> me did so before - it shows that I went down the
> same paths of thought :)
> -- 
> Regards,
> Diez B. Roggisch
> -- 

Do you Yahoo!? 
Read only the mail you want - Yahoo! Mail SpamGuard. 

More information about the Python-list mailing list