ANTLR v3 C# Code generator and Runtime library
Johannes Luber (Maintainer)
jaluber AT gmx.de
Kunle Odutola
kunle UNDERSCORE odutola AT hotmail.com
Micheal Jordan
Johannes Luber (Maintainer)
jaluber AT gmx.de
Contents
...
As of October 2007, the ANTLR source depot contains an early beta of the C# codegen and runtime for the upcoming ANTLR v3.1 release. Starting from the end of October, ANTLR daily builds of v3.1 have been available for those wishing to test the C# support with the new features of ANTLR v3.1. As before, development progress going forwards is likely to be sporadic.
As of May 2008, the C# target is in sync with the Java target of ANTLR v3.1. The new version breaks source compatibility with the old version. To a certain extent, regeneration of grammars does help, but certain fields have been renamed to follow .NET conventions, which means that the first is capitalized (example: .tree is now .Tree). The exception is .st, which is now .ST. Additionally, the new target CSharp2 has been introduced. The reason is three-fold: Firstly, the old target CSharp has to remain compatible to .NET 1.1. So the target can't take advantage of C# 2 features in the code generation templates and the runtime requires twice the number of files, effectively doubling the amount of maintenance.
Secondly, a certain bug fix requires a C# 2 feature or the change of templates for each time it appears - and this has to be done by the user. The details of doing so are found in a section below. Thirdly, because the backwards compatibility sucks majorly, I want to deprecate it without forcing people to abandon .NET 1.1 compatibility immediately. The easiest way of doing so was to introduce a new target which allows me to change even the code generation templates. As working on further enhancements will at least break binary compatibility, most of the changes will be done for ANTLR v3.2. During the life-time of ANTLR v3.1, the public API of the C# target will be frozen. If you wish to future-proof your grammar, change them to the CSharp2 target. It is planned to remove the CSharp target for ANTLR v3.3.
The C# code generation templates and the CLR runtime library are feature complete for both versionstargets. The C# targets leverage the existing C# StringTemplate implementations to support the broadest range of the features that ANTLR provides. The long open issue of unit tests has finally been tackled with the adoption of MbUnit and the inclusion (in the v3.1 version) of a wide range of tests for the runtime library. As before, basic sanity checks will done by ensuring that the sample grammars in the examples-v3 archive works as designed. This is currently a work-in-progess for the v3.1 release.
...
As with all other targets, the C# code generation and runtime are modelled modeled on the Java version. This means the C# target supports features such as grammar development/prototyping and remote debugging with the AntlrWorks GUI which is very important for ANTLR users.
...
The compiled libraries are found in the distribution under the directory "runtime/csharp". Both targets use the same runtime. Intermediary builds may not have the current version and can be compiled by using the build tools.
...
The V3 target generates code that is easily faster than that generated by the V2 target (especially the lexers). We probably won't be able to match the bare-metal performance of the code generated by Jim Idle's C target or Ric Klaren's C++ target, but , we expect to be very competitive with the other targets.
...
To specify that the ANTLR tool should generate C# code (rather than the default of generating Java code) for a grammar, set the grammar-level option named language to the value CSharp CSharp2 as shown below:
| Code Block |
|---|
grammar MyGrammar;
options
{
language=CSharpCSharp2;
}
// rest of grammar follows
....
|
...
| Code Block |
|---|
grammar MyGrammar;
options
{
language=CSharpCSharp2;
}
@parser::namespace { My.Custom.NameSpace.For.Parser.In.Combined.Grammar } // Or just @namespace { ... }
@lexer::namespace { My.Custom.NameSpace.For.Lexer.In.Combined.Grammar }
// rest of grammar follows
....
|
| Code Block |
|---|
lexer grammar MyGrammar;
options
{
language=CSharpCSharp2;
}
@namespace { My.Custom.NameSpace.For.Lexer }
// rest of grammar follows
....
|
| Code Block |
|---|
parser grammar MyGrammar;
options
{
language=CSharpCSharp2;
}
@namespace { My.Custom.NameSpace.For.Parser }
// rest of grammar follows
....
|
| Code Block |
|---|
tree grammar MyGrammar;
options
{
language=CSharpCSharp2;
}
@namespace { My.Custom.NameSpace.For.TreeParser }
// rest of grammar follows
....
|
...
Another problem, you may encounter while using the CSharp target, is that value types are initialized with null (happens e.g. while using labels). The cause lies in the following definition of CSharp.stg:
...
As you can see, only the inbuilt value types are supported. As adding value types to this map is an open-ended task, the maintainer is reluctant to does not make any changes in that structure . Until a new syntax to overwrite the default value explicitly is introduced, a private build along with the changed map is recommendedfor all users. Any changes have to be done by the user locally repeatedly for new used version of ANTLR. It is recommend to switch to the CSharp2 target and use .NET 2 or higher as target platforms, as the problem has been fixed there in an environment-independent manner.
Debugging with ANTLRWorks
...