To answer your questions in order:

1. In general, there's no formal way to prove that two programs do the same thing, and that has been proven. The next best thing is to device as many test cases as feasible and cross your fingers.
2. If it doesn't exist, it is not a trivial exercise since you have to write a parser for XBasic and add semantic actions to generate equivalent Perl code from the parse tree. It can be done though.

Hope this helps, -gjb-

In general, there's no formal way to prove that two programs do the same thing

That is true, but in this particular case the OP would be generating the code himself and would not just be given two programs and asked if they are equivalent. Thus, he could just prove that he is converting all simple instructions properly, that the execution model is the same (eg. instructions are processed sequentially except in conditionals and loops and those are processed in equivalent ways) and the equivalence of the programs would follow.

The next best thing is to device as many test cases as feasible

This is a commendable suggestion at any rate.



The stupider the astronaut, the easier it is to win the trip to Vega - A. Tucket

The form of BASIC I remember learning about 15 years ago was a very ugly language. There were no functions, so I would use gotos all over the place to roll my own. The code was a mess, and kludgy.

Even if a BASIC => Perl translator existed, or even if you could code one, you most likely would not want to translate your program. The 4000 lines of code would go from being maintainable in XBASIC to very cryptic perl and pretty hard to change without breaking anything.

I would recommend creating the program in Perl from scratch. Make use of an Object Oriented programming paradigm so your code is more efficient and maintainable, and write lots of test cases along the way to make sure everything does what it is supposed to.

Its a mess. The BASIC program just outputs some graphics. I would loved to have some numerical outputs that i could test against. But the code is just a mess and i fear breaking it during adding some functionility.

So its not trivial to collect output to test against.

The BASIC program just outputs some graphics. I would loved to have some numerical outputs that i could test against. But the code is just a mess and i fear breaking it during adding some functionility.

With a bit of work, you can treat the graphics as "numerical outputs". If the output is supposed to be pixel-perfect, the graphics files produced by the two programs will be identical. If there's some acceptable range of variation, perhaps there's a way to use one of the image-processing modules on CPAN to help with the comparison.

Computer: "Sir, did you perchance mean 'Perl'?

Captain Picard: "Didn't I say that?"

Computer: "Yes, you didn't."

Captain Picard: "Very well, proceed at your discretion."

Computer: "Am I allowed to choose which version of Perl to use?"

Captain Picard: "Please do."

Computer: "Working..."

Computer: "Good evening, Dave. Would you like to play a game of chess?"

Captain Picard: "Not that version, you stupid machine!"

Why even bother translating it? It's mission critical and it works to such satisfaction that it's considered a reference implementation - translated code should work identical to the original, instead of adhering to some specification.

Why take the risk of breaking it?

Abigail

BTW I thought about Inline'ing, but XBASIC isn't supported yet.

There is no specification - just code. The author did some comments within the scientific paper, but no mathematical formula or whatever were used to introduce the idea behind it. So i have the bare bone xbasic code which i want to play with. But i am reluctant to use xbasic, but prefer to have perl code (which the original author doesnt supply). I am looking forward to enhance it (DBI, XML, etc).

I especially fear that perl will suffer "numerical instabilities" when floating points were used.

20040417 Edit by Corion: Exchanged PRE tags for P tags

Edit2 by Chady: fixed link.

Don't use automated translators for mission-critical code. Hire someone to translate it for you. If it's mission-critical, it's worth something to someone, right? Well, make them prove it.

I don't know. If you have a lot of source code in Foo then it can be more time efficient and less error prone to re-implement a Foo compiler that targets something else than it is to translate all the code by hand.

I once had to help shift a fair sized app (about 20KLOC) from some old PDP-11 hardware that was implemented in a home grown bastard offspring of Lisp and Prolog. Rather that translate the code we just re-implemented the language in Common Lisp. I guarantee that doing a manual translation of the code would have taken a heck of a lot longer, and probably introduced a bunch of errors into working code.

That is one option. I tend to prefer, after a few times doing this, to rewrite the app. The number of improvements and bugs fixed tend to outweigh the number of errors. Granted, I have only worked with relatively young apps and rewriting them after they were implemented by junior developers. *shrugs* YMMV, as with everything.

------
We are the carpenters and bricklayers of the Information Age.

Then there are Damian modules.... *sigh* ... that's not about being less-lazy -- that's about being on some really good drugs -- you know, there is no spoon. - flyingmoose