Hi Mick,
If you've written an LLParser for VBScript and are currently generating an AST, you may have some level of success creating a conversion tool where you parse the AST from VBScript and generate C# code that is largely equivalent. I actually used a similar approach once to do the opposite... take a C-like language and generate VBScript from it. Your rate of success will be directly related to how much detail you currently parse from VBScript.
To take a crude example... consider the following VBScript:
Dim x
x = 1
Your parser might generate an AST with a "VariableDeclarationStatement" and "AssignmentStatement" nodes. Assuming your "VariableDeclarationStatement" also tracks the "Identifier" and your "AssignmentStatement" tracks similar information, you would be able to convert that into C# like:
object x = null;
x = 1;
Since VBScript is typeless, your first challenge may be deciding which default type to use. The object type works, but is really not what you'd want to use for more common types like string, int, and bool. You may even have some luck using "dynamic" in C# instead.
Basic VBScript syntax should be fairly easy to convert, but there are a lot of edge cases to consider.
If your customers don't declare their variables (optional in VBScript when not using "Option Explicit") your AST will not have any declaration statements to convert. If they do have declarations but put them after first use (perfectly valid in VBScript), you'd have to make sure you move the declaration to before first use in C#.
Error handling statements (like "On Error Resume Next" and "On Error GoTo 0") do not have to appear in pairs and thus cannot consistently be converted to C# try/catch blocks.
Now trying thinking about converting all the usage of "Scripting.FileSystemObject" or "Scripting.Dictionary" COM objects to C# equivalents where you aren't just converting syntax, you're completely altering object usage and having to track which variables refer to which object types.
You will also run into ambigous syntax where you cannot easily tell the difference between array access and argument lists like:
Foo = IsThisMethodOrArray(1).Bar
I've worked a lot with VBScript parsing and all the annoying "features" of the language, so I know it's not a straight-forward conversion and many, many compromises will have to be made. But even getting a user half-way through a conversion will save them time.
If you decide to move forward, you can essentially start at the top of your AST and recursively iterate the children where each child AstNode type has logic to output the equivalent C# (perhaps just appending to a StringBuilder as you go). Any AstNode that cannot be converted (or has yet to be supported) could generate placeholder comments of what needs to be done manually.
So "yes", SyntaxEditor can help with the conversion, but you'll still have some pain points. Best of luck if you decide to move forward with this!
