Hi,
> Ok, thats clearer. This whole thing sounds familiar
> - the technique you
> describe seems to resemble continuation passing
> style. For a brief
> discussion read here:
>
>
http://www.ps.uni-sb.de/~duchier/python/continuations.html
>
> Python has a continuation-based interpreter
> implementation - its called
> "stackless python". Google for it. It certainly is
> interesting.
That's interesting. I heared of stackless pyton a few
days ago, I will have a more careful look at it.
> And I don't see that the ast is more complicated, at
> least implementation
> wise - in fact, your method requires more analysis
> as for each statement
> its pollible successors have to be computed and made
> known to it - where an
> ast node only knows about its children that more or
> less directly stem from
> the syntax analysis.
Not really. You think in this way, maybe because you
know more about AST and less about that technique I
mentioned. I thinked in the opposite
way because I know different things better.
Hehe.
> I have to admit that I don't know if
> continuation-based evaluation has
> inherent performance-gains. The only thing I can
> think of is that you don't
> need a stackframe in some cases as tail-recursion -
> useful, but not so
> common that one would expect significant performance
> gains there. But as I
> said - I'm not on sure ground here.
I'm not sure either. Certainly it depends very much in
the implementation. If anybody want, we can make some
tests to check. I don't know if it's important,
because it seems people dosen't really care about the
efficiency of an interpreter (as long as it is not
really really too slow).
> Can you elaborate on what you consider beeing an
> unefficient recursive call
> and where there is a difference between your method
> of evaluation and the
> ast-evaluation I mentioned? After all, the
> ast-evaluation is a postorder
> traversal which has the same complexity of a depth
> first search - the only
> difference beeing the latter one using a fifo, the
> forme a lifo for
> managing the list of untraversed nodes. I don't see
> any difference here.
Sorry maybe I didn't understand that part correctly
and took grant that it would be implemented in
recursive way. I just wondered if the following can be
extended for arbitrary length arithmetic expressions:
Assignment("foo", BinaryOp("+", Get("a"),
BinaryOp("*", Get("b"), Get("c"))))
> I don't have negative opinions about yuan and by no
> meants want to
> discourage you developing it. Its a nice project.
>
If I upseted you or anybody here by un-properly used
words, please forgive me. I always feel my english
must be improved :)
Best regards,
Limin
__________________________________
Do you Yahoo!?
Yahoo! Mail - Easier than ever with enhanced search. Learn more.
http://info.mail.yahoo.com/mail_250
--
http://mail.python.org/mailman/listinfo/python-list
