On 3/18/2012 0:28, Michael Torrie wrote:
I am familiar with how one
might implement a decompiler, as well as a compiler (having written a
simple one in the past), but even now I don't see a connection between a
decompiler and the process of converting a knuth algorithm into a python
python implementation. I was hoping you would shed some light on that.
But alas, I'm not really as much of an "interested reader" as you would
like me to be.
Many ASM languages don't have structured control flow statements but
only jmps, which are roughly equivalent to gotos. A good decompiler will
need to analize the net of jmps and try to rewrite the code using
structured control flow statements.
The idea is to maximize readability, of course.
Here's an example of rewriting:
<snip>
Thank you. Your example makes more clear your assertion about "labels"
and how really A1 and A5 were the only real labels in the example.
Though I still do not really see why "states" is not a good equivalence
for labels in this case. As well, Roy's idea for doing the state
machines, which works equally well as the nested if statements, is more
pythonic, which is generally preferred in Python.
What I don't like about the entire issue is that (pseudo-)code shouldn't
be cut and pasted or blindly ported to another language.
Python is a very expressive language. I don't think you like it when
someone writes C code in Python. Now we're writing ASM code in Python!
If you want to emulate a DFA, do it, but if you want to implement an
algorithm whose pseudo-code happens to use labels and gotos, please use
higher-level control flow statements (unless you're pressed on time and
you need it done yesterday, of course).
Regarding labels and state, I simply meant that they're completely
different things, in fact this program has two labels but infinitely
many states:
A1: cur = cur + 1
A2: goto A1
I was being pedantic, to say it your way ;)
Kiuhnm
--
http://mail.python.org/mailman/listinfo/python-list
