Using ANTLRv4 as a third party parser

Hello,

Unfortunately in ANTLR4 they made enormous breaking changes and really our ANTLR add-on isn't useful any more for that version since all the parsing is done on the fly as items are examined. They also did away with the AST generation code in favor of their visitor pattern. There is some information in this blog post:

http://blog.actiprosoftware.com/post/2014/01/24/SyntaxEditor-for-WPF-ANTLR-v4-Support.aspx

After reviewing ANTLR4 in depth a while back, there isn't much for us to support. The language authors (you) would need to make a low-level IParser implementation that calls your ANTLR4 parser and returns some form of results. Unfortunately there's nothing we can "wrap" any more like we did in ANTLR3. But by you creating an IParser-based class to call your parser from SyntaxEditor, you can still easily call into ANTLR to do your parsing in a worker thread, since any IParser service implementation supports our ambient parse request dispatcher.

1) Sorry, we don't have any articles on working with ANTLR4.

2) The main concept per above is that you need to design an IParser implementation that wraps a call to your ANTLR4 parser.  Then follow all our documentation on parsers (how to register the parser service on your language, set up the ambient parse request dispatcher to support worker threads, etc.).  Each IParser.Parse method is passed a parse request that contains an IParseRequest.TextBufferReader property.  That gives you access to the raw text to parse and you'd likely need to write a wrapper around that for your call to the ANTLR4 parser so that it can get at that text.  Using TextBufferReader would be faster than doing a full IParseRequest.Snapshot.Text reconstruction each parsing cycle since rebuilding the full document text is a relatively "expensive" operation.

3) Check out the "SyntaxEditor / User Interface Features / Adornment Features / Squiggle Lines" documentation topic.  If you have a ParseErrorTagger provider service on your language, and your IParseData result from your IParser implements IParseErrorProvider, then it will show squiggle lines.  The "Getting Started #5" QuickStart sample also shows this.

4) Per above and the blog post, there's nothing we really can do to make a helpful add-on for ANTLR4 due to the infrastructure direction they went with it.  Everything needs to be specialized for your language in ANTLR4, which wasn't the case in ANTLR3.  But that being said, SyntaxEditor supports calling into any third party parser like ANTLR via the IParser interface, and any IParser can take advantage of our multi-threaded parse request dispatcher.

Thank you support team, I really appreciate it.

Especially, the answer about second question really opens my eyes. 

I think I have to make clear something. 

        1) I use Winform, but I can't find IParser on your documentation. Is it on the WPF version?

        http://blog.actiprosoftware.com/post/2009/08/11/SyntaxEditor-for-WPF-to-add-integration-with-ANTLR-parsers

        2) Quite close with the first, in the winform how can I register the parser service? Do you have relative documentation? 

Oh my apologies.  All the talk of ANTLR and the WPF article links you posted had me thinking of the WPF version since that's the only SyntaxEditor where we have an ANTLR integration add-on, but it is for ANTLR3.  I see now you meant the WinForms version.

The older WinForms version does support parsers (called semantic parsers there) and they can be run on a worker thread.  But the process to add a custom parser is admittedly more convoluted than the better design in our newer WPF version.  The best thing to do there would be to look at the SyntaxEditorSampels/Languages/SimpleAddon/SimpleSyntaxLanguage.cs file.  There the language implements ISemanticParserServiceProcessor and has a ISemanticParserServiceProcessor.Process method that gets called back into by the SemanticParserService.  There are two PerformSemanticParse method overrides.  One is the core one called when a parse should occur.  It queues up the SemanticParserService request.  Later that Process method is called which will then invoke the other PerformSemanticParse overload.  That is the one where you'd place your code to call into ANTLR.  Again, all of this is a lot easier to do with the WPF version.

On a side note, we are working on a major "SyntaxEditor vNext" project as described in our blog where we are unifying the codebases of the WPF, UWP, and WinForms SyntaxEditors to have a single common API.  The API will be pretty much the same as the current WPF version's API, but with some tweaks.  That API is much better than the current old WinForms one.  Once that project is complete in a few months, everything we're describing about the WPF version's extensibility features will be available in WinForms too.

Thank you support team.

No nevermind, that was my bad. I searched ANTLR4 without realizing Winform/WPF since there was lack of reference. Anyway, I want to make one complete thread about wiring up third-party parser as a contribution.

I see your detail instruction. I appreciate it. However, still, I have some problems. Obviously, every data types are not matched with the output of ANTLR4, so it seems like I have to wrap up every class. Before applying your implementation(ISemanticParserServiceProcessor.Process), I should implement Token class first and then override CreateInvalidToken and CreateDocumentEndToken. In my opinion, it might be easy to implement from the bottom instead of using outputs from ANTLR4.

My initial goal was checking syntax error. To achieve this, I thought I need to wire up the parser created by ANTLR4.

1) Do you have any suggestion for checking syntax error? (currently, I have done with the iterating token stream, but it does not guarantee performance.)

Besides, thank you for the release alert of the new version and this is a bit out of topic.

2) Do you have the plan to give color marks on the scrollbar within the SyntaxEditor?

For example)

http://www.techdreams.org/wp-content/uploads/2011/11/google-chrome-scrollbar-higlighting.png

Hello,

1) When the parsing completes, if the editor.Document.SemanticParseData property ends up with a parse result object that implements ICompilationUnit, it will use the SyntaxErrors collection on that ICompilationUnit and will display syntax error lines.

2) For the scrollbar with marks, that is something we have written down to look into in the future.  Right now we're focused on getting SyntaxEditor vNext finished first because it's a major effort, and there are some really nice new feature areas coming in it as well.  Once that is out, the scrollbar enhancements is something we'd eventually like to check into.

Thank you for all!

I will try with Winform at first and then with WPF as you said it has the better design than Winform and also the SyntaxEditor vNext will almost similar with WPF.

and if I have a new question, I will post here Thank you again.

I marked the first answer because it contains big step to wire ANTLR4 up.

Best Regards

Junhong

Any roadmap for your SyntaxEditor vNext? We have been using SyntaxEditor for Winforms since 2006 and now we need to edit our "own" language. We will use ANTLR4 for parsing and will not integrate it with Winforms and wait for vNext.

Hi Raul,

While we can't offer a target date on SyntaxEditor vNext, it is a top development priority right now and we will continue updating our blog as we progress.  

Thank you. I will keep reading your blog and waiting for any news!!