Conversion from proprietary satellite control script language

[TJ Judson]

I've culled through all of the discussions on the "goto" statement. 
I believe the summary is:

1. It doesn't exist, but it would not be hard to add (The necessary
opcodes are there -- well, the one you need: JUMP_ABSOLUTE --
mwh21 at cam.ac.uk)

2. There are a few "good" uses for it:  (jump to cleanup code, for
use by code generators, as a performance optimization -- John
Mitchell)

I have a new and much better reason :-) to add a goto statement... To
support conversions from other, existing scripts/languages.

I need to convert an extensive set of scripts from a proprietary
satellite control language to some new, open source scripting
language.  Having looked at them, I think Python is superior to the
others.  I can handle everything except for the label/goto construct.
 This is used infrequently, but enough that it poses a major problem.
 I need to convert millions of dollars of existing scripts, so
complete automation is the only answer.  It's cost prohibitive to
rework the logic of the original scripts.  As I said, I can handle
everything except for the goto.

I'm afraid my only other answer is to use a language that supports
"goto", like Tcl.

Question/Plea:
--------------
If it is easy to add, then wouldn't this be a good feature to add for
the sole purpose of easing (promoting) the conversion to Python?  I
think it would be neat if Python were being used to fly satellites. 
There are many "old" scripting languages out there and most of them
have a goto/label construct.

It could be added as a standard feature with a strong warning
regarding its use.  Or it could be provided only as a patch...

If the powers that be decide "too bad, you're screwed", does anyone
have any pointers on how I might add this myself?  I have built my
own interpretor before, so I have some hope of being able to figure
it out on my own, but I haven't yet poked around the Python
internals.  I really wouldn't want to have my own version.  I hope
the powers that be see the argument that it would be better to add a
less than perfect construct into the language, for the sole purpose
of gaining more widespread use.  With more widespread use, the
language will ultimately grow and become better than it otherwise
could be.  Providing this "necessary evil" opens up the possibility
of many more people being able to adopt Python in favor of their old
languages.

(Sorry for drumming up what is a well worn subject, but I'm
desperate)

Thanks,
-TJ Judson
judson at iname.com



__________________________________________________
Do You Yahoo!?
Send instant messages with Yahoo! Messenger.
http://im.yahoo.com/