This project has moved and is read-only. For the latest updates, please go here.

Willing to Contribute? Here's a list of tasks!

Jul 9, 2011 at 7:18 PM
Edited Jul 10, 2011 at 12:34 AM

Would appreciate any help as we move to Beta and Release!

Please post links to your discussions for project items to this thread.

Jul 19, 2011 at 8:50 PM
Edited Jul 20, 2011 at 1:00 AM

P1: LineContinuation terminal discussion:

Jul 20, 2011 at 1:00 AM

P21: Implementing fast compiled delegate for creating AST nodes:

Jul 20, 2011 at 11:37 PM

Important: "Automatic conflict resolution" page was edited. Changed implementation suggestion:

Jul 29, 2011 at 12:38 AM

Hi, Roman!

>Automatic conflict resolution

Isn't it what NLALR algorithm was supposed to do? Why did you decide to remove it?

Jul 29, 2011 at 1:00 AM

yes, the goal is the same, but the method is different - NLALR tries to resolve the conflict automatically (!) by extending the state set with non-canonical states. I struggled with NLALR for several months, and it never worked properly on real-world grammars. The state count exploded, parser construction time was huge, and no resolution. The trouble was that a complex grammar like c#, in initial plain version, might have lots of different LALR conflicts, of different nature - not only mentioned in this project item. When NLALR takes over, it tries to "fight" them all, and things get out of hand. In any case, you need a careful hand of human grammar author to guide the resolution of each type of conflict. 

So I abandoned NLALR. 

This suggested feature is not so much "automatic resolution", this is a bad title. User (grammar builder) provides necessary resolution algorithm (lookahead hints), and the issue is to make parser "understand" these hints.

Jul 30, 2011 at 10:15 PM

Hi, Roman!

Thank you for the explanation. That's sad... NLALR concept looked like a silver bullet.

>not so much "automatic resolution", this is a bad title

I guess it should be "Semi-automatic resolution" instead :)

I'll try to look into this task if you don't mind.

Jul 31, 2011 at 6:26 AM

Sure, go ahead. thanks!


Aug 20, 2011 at 8:33 PM

P6: Heredoc terminal:

Apr 4, 2012 at 10:16 PM

Implemented P9 - support for nested comments.  Sent pull request.

Apr 4, 2012 at 11:37 PM

thanks! we'll look at at it and pull it in


Apr 15, 2012 at 5:45 PM

(to denito, about nested comments)


Looks good. Just a few notes:

AllowNested - pls make it a public field, just to be in line with other fields in the class; and don't initialize it in constructor, .NET sets it to default value anyway

The check you do to disallow Nested&LineComment - it should be done in Init method, adding error message to grammar errors

Please add unit tests, try to cover some valid/invalid inputs



Oct 13, 2012 at 10:39 PM

P8: Validated RegEx's:


Oct 16, 2012 at 6:09 PM

That's not what I meant in P8. The idea is to enhance IdentifierTerminal with optional validation Regex, not to invent new Regexes.