As we’ve been posting, a large piece of the upcoming 2011.1 round of releases will be the first public beta of the SyntaxEditor .NET Languages Add-on for WPF and Silverlight. This add-on contains advanced syntax language implementations for C# and VB that improves the SyntaxEditor code editing experience of those languages for end users. While the first beta won’t yet have automated IntelliPrompt (that is coming in the future), it will have complete background parsing of C#/VB code into full ASTs, reporting of syntax errors, and automatic outlining.
The add-on is a massive undertaking, even with the advanced LL(*) Parser Framework that comes with SyntaxEditor for WPF and Silverlight. The good thing for our customers is that it has also driven a number of wonderful enhancements into the LL(*) Parser Framework. These enhancements will be the focus of the next several blog posts, since they will be fully available to anyone developing custom grammars using our framework.
Blog Post Series
These posts will be included in this multi-part series:
All the features discussed here are currently in closed beta testing, but will be available with the release of WPF Studio and Silverlight Studio 2011.1 in the coming weeks.
LL(*) Parser Framework
If you aren’t familiar with our free parser framework that is available with the WPF and Silverlight SyntaxEditor products, please read through our original series of posts that discuss what it is and how it works. It combines the best concepts from other parser frameworks such as ANTLR, MGrammar, and Irony with our own ideas and the result is a very innovative grammar design where you write your grammar directly in C#/VB code.
A grammar is a set of rules that describe how to parse a language’s code. In the case of our parser framework, we use this grammar to output an AST (abstract syntax tree) of the document and report syntax errors to the end user.
Both our Web Languages Add-on and .NET Languages Add-on use this core grammar-based parser framework as the foundation of their parsers.
Type-Specific AST Nodes
The original iterations of the parser framework made it easy to generate a completely generic sort of AST node, where each node had a string value and optional child nodes. This works great and the XML parser in our Web Languages Add-on uses this setup very successfully.
When we got to designing the grammars for C# and VB though, we wanted to have type-specific AST nodes, meaning a distinct .NET class for each type of AST node.
Take this snippet of C# for example, a simple class declaration:
With the default AST nodes, a resulting AST would be something like:
1: ClassDeclaration[
2: Name[
3: "Foo"
4: ]
5: ]
You can imagine how large the AST grows as you get into much more complex code since an AST node is typically used to describe the context of its contained nodes.
Now instead, assume we have a class called ClassDeclaration like this:
1: class ClassDeclaration : AstNodeBase {
2: public string Name { get; set; }
3: ...
4: }
What we set out to do was make it so our grammar could create an instance of ClassDeclaration and assign the value Foo to its Name property. So instead of having three simple nodes, we have one type-specific node with a property set.
A benefit of type-specific nodes is that since they are .NET classes, you can fully extend them with partial classes, etc., thereby adding helper methods or other features to them.
Next Steps
As we’ll show over the next few posts, we’ve enhanced our grammar syntax to support both the default simple node creation as well as type-specific node creation. You have the ability to choose which you’d prefer to use, and can even use them together. The default simple nodes get you up and going very fast but you may find that you want to harness the power of type-specific nodes instead.
In the next post, we’re going to look at Language Designer application enhancements that help support type-specific AST nodes, which includes complete AST node class generation.