Here is my understanding of what it takes to build a Basic to C translator. I want to believe that I'm going to see a benefit over ScriptBasic's method of creating compiled user applications. From my standpoint, I see no benefit in self translation. The goal is to take Basic source in a text file format, parse it, translate Basic structures to their C equivalents and add the require C framework and declarations.
If I had the time to write a Basic to C translator, this is how I would approach the task. I think too many translator developers lose focus along the way an get wrapped up in building a clone rather than a translator.
I would use ScriptBasic for the translator as it's the best language I know of to deal with huge strings, arrays and dynamic structures without having to define or declare a thing. That in itself is a time savings of at least a 1/3 of the project's time to completion estimate. The real benefit I see using a translator over a dedicated Basic compiler (PB, FB, ...) is the ability to customize the translation to best fit the environment your after. I find it most efficient to break up my code in modules, load them in my editor and run the main translator script in a console which includes other static components of the project.
I see the job of translating Basic to C as a multi-pass parsing effort building the C equivalent code. There are a number of Basic to C translators that are open source so it shouldn't be too hard to figure out the best method of doing things with all the examples of working code to use as a guide.
I keep asking myself if giving up simplicity, stability and flexibility is worth the few seconds of speed I may never notice with the business applications I write. ScriptBasic applications compiled to C typically have a < 50 KB footprint, load/run as fast as any compiled equivalent program I compared with. I guess if your doing games or OpenGL based applications, using a translator might matter.
