Give up Razor and Skeleton for Code Generation

[mayanje]

According to issue #991 it came that with current translation templates based on Razor scripts, we fail to generate an exact code for situations like thoses described in #991.
So we need to write C# code for handling function declaration code generation.

Sub-tasks:

• SymbolDefinition and SymbolReference code cleanup and refactor? #1048 Review and Update Skeleton xml file xsd schema (A02.T02)
• Create a StackedProgram Node #1049 Specify the attributed grammar of a Skeleton.xml file(A04.T01)
• Write the SAX Parser of a Skeleton.xml file (A04.T02) #1150 Write the SAX Parser of a Skeleton.xml file (A04.T02)
• Implement the instantiation of Razor Parser for a target script language. (A05.T01) #1151 Implement the instantiation of Razor Parser for a target script language. (A05.T01)
• Implement the transpilation of a C# Razor Script to C# instructions (A06.T01) #1152 Implement the transpilation of a C# Razor Script to C# instructions (A06.T01)
• Generate C# execution code for Skeleton actions on Nodes. (A07.T01) #1153 Generate C# execution code for Skeleton actions on Nodes. (A06.T01)
• Generate the Skeleton.cs file from the Skeleton.xml file. (A08.T01) #1154 Generate the Skeleton.cs file from the Skeleton.xml file. (A08.T01)
• Adapt Codegen to work with the generated Skeleton.cs file. (A09.T01) #1155 Adapt Codegen to work with the generated Skeleton.cs fil. (A09.T01).
• New codegen #1178 PullRequest Newcodegen
• Add a MSBuild task to auto generate C# Skeleton file. #1218 Add a MSBuild task to auto generate C# Skeleton file.

...To complete

[smedilol]

Just to be sure, we can give up Razor for all the generation process.
Even type, :: can be done in C#.

[smedilol]

Here's what we need for our codegen:
Create new generator easily:

• TypeCobol to Cobol85 - where Cobol85 is a general code
• TypeCobol to Cobol85 + EI - with parts specific to our company
• TypeCobol to Cobol85 + EI v2 - Version 2 - with parts specific to our company
• TypeCobol to Cobol2002 - when we'll have a Compiler that support Typedef
• ...

Each generator is assembled with different sub-generators for each concepts of TypeCobol:

• Typedef and type
  • Typedef to Cobol85
  • Typedef strict to Typedef weak or strong (if we target a Cobol 2002 compiler)
  • Keep typedef strict, if in the future we have a compiler that support Typedef strict
• type bool and set to false
  • Cobol2002 support set to false so in the future we could choose to generate thing differently
• unsafe
• operator ::
• index qualification
• Set up by/down by with pointer
• procedure and call to procedure
  • For this one, we'll have at least 3 versions:
    • TypeCobol to Cobol85 - where Cobol85 is a general code
    • TypeCobol to Cobol85 + EI - with parts specific to our company
    • TypeCobol to Cobol85 + EI v2 - Version 2 - with parts specific to our company
  • We could also need a very basic template support (to be discussed)
• namespace, using
• future TypeCobol features...

For each concepts listed here, we could choose to do nothing during codegen because the target compiler support the feature.

[mayanje]

:: Is handled by a C# code and not by Razor, even if there is an action called Qualifier, this action is first called before any Razor or Skeleton action.

[mayanje]

For the requirements (Needs), yes the new Codegen must effectively support various generation scheme, so it must be flexible and customizable, and Node directed.
For the notion of basic template support, I think we must start thinking about tree pattern matching towards a rewriting system.

[mayanje]

Another Idea for code generation customization, is to be driven by the parser, that is to say to use the same Cup parser used to create the AST, but now to perform CodeGen action on specific nodes, while still being Node directed.

[mayanje]

Ok this is another Idea: It seems to be in contradiction, but why give up razor and skeleton? Why not create our skeleton C# code generator tool. The tool will take our current Skeleton.xml file and generates a Skeleton.cs file to be compiled. The Skeleton.cs file will not call razor or use razor , but it will contains substituted code for all razor pattern as C# code for condition's type node.

I like this idea.

So it will be possible to generate various Skeleton.cs file depending on options or output format.
And our current generation scheme is preserved.

BUT OF COURSE WE GIVE UP RAZOR, but we keep its pattern syntax.