Dec 30, 2012 at 2:54 AM


Due to the now out of date articles at CodeProject and other locations, am a bit confused as to what is actually needed to get a fully functional sample working.

Do we need Irony.dll AND Irony.Interpretor.dll?

I'm asking because AstNode, which I thought was integral to the concept of parsing, is not in Irony.dll, but in the Interpreter dll...

For a proprietarary DSL of chained commands (eg: "Ring Bell;Go Left;Show the desktop;") can one build with only the Irony.dll? Or has the project grown such that both dll's are needed for most grammars, even if not evaluated?



Jan 1, 2013 at 1:47 PM


I am in the same boat as you are.  You need to bean expert in C#, BNF, Comiler theory and other areas in order to 'wrap your head around it'.

Just follow the (very accurate, alas not for the lowest level beginner) instructions provided by Roman.  The code, samples, and everything you need is right there.  All samples work as advertised.

Roman did an amazing job at writing the (FREE) code but he is not tech-support nor extremely patient.

Suggestion: Do more work on your own first.  Irony has now been used by many others to show folks like you and me how to do simple stuff.  Many of those projects have running sample code so you can explore how the engine work beyond adding numbers.

Google can get you pretty far.


Most of us are not nearly as smart as you, just ignore the question you deem stupid and have a happy new year.



Jan 11, 2013 at 5:38 PM

Hi Roman,

Happy New Year!

Yes, it's okay to be pissed, but it doesn't help to wear your heart on your sleeve so often. Again, thank you for the great (FREE)) toolkit. We all appreciate it. It's a five-star effort in my books, even with its warts.

Part of the issue is the dichotomy between the ease and elegance of producing a first parse-tree, and the relative (even extreme) difficulty of then producing an AST using the (non-intuitive) Visitor Design pattern of your examples. Not knowing of the Visitor design pattern, I completely rewrote the AST code without it as It's unelegant, and probably overly compelx, but it is more intuitive and uses generics. It also works out of the box for making an AST. Anyone struggling (as I did) to make an AST, and who is unfamiliar with the Visitor Design Pattern, could probaly do worse than to check out If nothing else, looking at how an alternate structure was built on the bare skeleton of Roman's Visitor pattern might help in using the later.



Jan 11, 2013 at 10:55 PM


My sincere apologies for wearing my frustrations on my sleeve when posting a less than 5 star review. The inability to connect the dots in between earlier articles and the current state of the library in order to unlock the power of Irony is certainly more of a reflection of my own ignorance in this particular field and lack of time to become an expert in parsing. As stated elsewhere, I believe the Irony library shows great promise, and clearly already of value to many.  

Regarding the rating I gave: I was not commenting on just the functionality -- which is clearly valuable to many -- but as stated, on the whole experience of downloading the kit, referring to the Documentation tab, prior Code Project articles, Googling, and attempting to understand enough of how it worked to modify it.  With the available information, it was certainly more frustrating than other open source libraries I've encountered.

But I also certainly understand the major effort invested by you, at no cost to others, sustained only by positive comments. It's important to have reasons to continue. For that reason -- as It appears that comments and rating can be updated or deleted -- I am happy to delete my 3-star entry stating that there was insufficient documentation to use the library effectively in the week's time I had available.  



Thanks for the encouraging statement that all samples are up to date: it was clear that the samples in the Kit all compile and work, and parse grammars.
What was not clear from the kit what to do with them after that. Next break I get, I'll give it another shot.


I think you expressed clearly what I was bumping into: "Part of the issue is the dichotomy between the ease and elegance of producing a first parse-tree, and the relative (even extreme) difficulty of then producing an AST using the (non-intuitive) Visitor Design pattern of your examples." I'll look again at your helper library more in depth at some point in the future.

As you obviously have slogged through it and understand at this point the pitfalls that newcomers would face when first approaching the library, maybe you might consider offering to collaborate with rivantsov to provide some pages for the Documentation tab? The subject matter that Irony encapsulates is uncommon, and any assistance to make it more accessible to newbies would be valuable. For example, It would be most interesting to understand first how to do it with just the base libraries -- with out all of the Kit's helper classes already in play, and then why the addition of your library makes the process more intuitive?




Jan 14, 2013 at 7:51 AM
Edited Jan 15, 2013 at 4:35 PM

I would like to try to explain why Irony often seems so difficult - and frustrating - for newbies. The reason is what is known as 'abstraction leak'. A sudden, unexpected, quite horrifying leak. Here's what happens, and what happened to you.

 Parsing and compiler construction in general is quite complex area. There is a lot of math behind it (not very advanced, but quite considerable in volume). To start doing something in this area, you have to pay your dues - spend some time learning the theory. You have to read at least one book on compiler construction, carefully, page by page. You cannot learn it on the job as you go, like other programming areas. You have to know the theory. It is not a secret for anybody who graduated from computer science - a course on compiler construction is required, and if anything, you remember this is a big and difficult area. For unlucky guys without computer science degree (like myself, I did electrical engineering and learned programming mostly by myself) - this is a fact to be discovered later. I myself spent several months struggling thru Dragon book. 

As far as I know, for any other parser construction tool (Lex/Yacc, Antlr, Gold, SableCc et), knowing the theory is an upfront requirement. That is, you have no chance of understanding anything about the tool, or how samples work, without knowing what is LR/LARL/LL, shift/reduce, lookahead and other stuff. The parsing automaton is right on the surface, with all its complexities.

Irony, however, might give a different impression to a newcomer. You download it, run the GrammarExplorer, then try the samples. Ok, it parses stuff, shows you the output as a nice tree. It even evaluates some expressions. You look at sample grammars, and it seems like you understand what's going on and how it's done. The reason I think is that Irony defines a set of 'abstractions' which hide LALR parsing complexities. Terminal, NonTerminal classes, and definition rules - these are all abstractions hiding a lot of things behind. Basic abstractions are implemented in such a way that language definitions seem easy on the eye - which might give a wrong impression that the engine behind it is easy as well. 

No, it's not, and troubleshooting it is not easy either.  Let's say our newbie, after exploring samples, decides to implement his own language and grammar. Definitely, initial version would have some imperfections. Irony would react with something quite unexpected - cryptic messages like 'shift-reduce conflict in State S100 for lookaheads X,Y,Z' - which give a little shock to the programmer. The name for this is ABSTRACTION LEAK. Irony's abstractions leak - and what is leaked is the manifestation of LALR complexities behind it. At this point our hypothetical newbie is lost, and starts blaming lack of documentation, no xml comments, etc. 

By contrast, for programmers with prior experience/knowledge of parsing (especially when they come from other parsing kits) - shift-reduce conflict is not a showstopper. They know what it is, and how to fix it. And they appreciate Irony's decent diagnostic facilities - like states printout, parsing log with immediate navigation to parser state, and integration with VS in general - you can debug through parser engine if you need to. Many folks out there use Irony in their projects, and some even share their experiences in articles and blog posts - which proves that Irony's lack of documentation is not a showstopper, but only if you are not newbie for parsing.   

No documentation - I know it's bad, and I'm not trying to say it's not needed. But here's the trouble. There is no way for Irony to fix the abstraction leak and shield the programmer from these theory-heavy error messages - at least I don't know any. It cannot convert them into something like 'change X rule in such-and-such way'. The only way is to give a clear message in terms of LALR theory, help identify the trouble (state productions printout); and give an advice - if you don't know what this mean, then go read the Dragon book. No other way, period. So even if I documented every class/method/property in Irony code base, that would not help at all if you don't know how LALR parser works. 

And Irony's quick start quide might look like the following:
Part 1. Single statement: If you don't know what LALR(1) is, go read the Dragon book, or any modern book on compiler construction.
Part 2. A few pages describing mapping of LALR(1) concepts into c# classes in Irony.

Other thing, about problems with Interpreter. I don't think Visitor pattern is a core problem here. I should emphasize that Irony's interpreter and evaluator of arithmetic expressions should be viewed as an extended working example, not definitive guide of 'how to define AST'. There are many-many-many ways that programs can be 'executed': consider for example, Json grammar - defines in fact data format and json deserializer; Wiki grammar/parser - example of converter from one text into another; expression evaluator - evaluate all as arithmetic expressions. And there are many other languages that define program 'execution' as completely 'other' things. So Irony's Interpreter and a set of AST nodes is just one case of 'program execution' concept, using a very common use case - expression evaluation. It's AST node set and the whole concept is VERY specific to the expression evaluation. The message is: here's how to do it in this particular case; invent your own for your language, Irony hopefully can support this. 

It's past midnight Sunday here in Seattle as I'm writing this. That's the time I can spend on Irony. Tomorrow morning I will drive to work, and will be doing things that have nothing to do with parsing. It's life - it sucks without documentation, and without many other things, but that's all I can offer.


Jan 14, 2013 at 1:19 PM
Edited Jan 14, 2013 at 1:24 PM

Excellent explanation Roman, I completely agree with you; and of course documentation has importance, but in this case documenting the library will not hide the complexities behind compiler construction and grammar specifications. Irony, even with a full fledged documentation cannot become a repetition of the dragon book, and in the epoch of Google... well... you need to go and do your homework instead of taxing someone else for not watering down the problem to a level that I can understand. Studying is a personal responsibility.

Just as a curiosity, something that cough my eye, and related more to design choices than nothing else. Why to include a regex terminal? It feels weird to me to mix parsing paradigms.



Jan 14, 2013 at 2:38 PM


I fully appreciate everything you mentioned and have great respect for what you have done.

One of the greatest aspects of your legacy is enabling folks who are less informed about the complexities of grammar, parsing, etc. to be able to use Irony.

Sky (and I) are in that crowd.

With that, the audience to which you play is larger, more diverse and with a lower average level of comprehension of your work.

I did not mean to be mean or sarcastic and I appreciate the time you took to respond.


Jan 14, 2013 at 9:48 PM

Jorgeleo - 

about RegexExpression. Why not? It's not mixing of paradigms, just particular tricky terminals can be handled by regexes. Not like other solutions that rely heavily on regexes. There might be situations when it solves a problem easier than any alternative (custom terminal) so it's handy when perf is not critical. Read this thread, at the end:

There are folks that prefer RegexTerminal!


Jan 14, 2013 at 10:06 PM

So syntax sugar for people that cannot be bother with:

float := Integer + "." + Integer

While is not mathematically correct because ti does not considers scientific notation, it will cover his example

You know what? I understand you, I do support your original argument on that thread, and I still think that regex terminals is the goto of the parser, but if it saves some aggravation with some tricky terminals, I'll do the same. 

But then beymelamed is correct in the sense that Irony is such advance and simple tool to use that it fools people into thinking that there is no need to learn grammar theory, or that there is no need for though process shifting. And that puts Irony in the hot seat.

Still looking for help with the documentation? If you give me a week or so, I'll prepare a simple document with the basics on the grammar construction for you to review and publish if you wish.

Jan 14, 2013 at 10:47 PM

documentation - that would be great! Let's start building doc tab, one piece at a time


Jan 14, 2013 at 11:42 PM

In the meantime, until the Documentation tab gets filled in...I'll go order some books.

You mentioned the dragon book. Which it appears to me to be getting me in deeper than just languages.
With finite time and all, what is your opinion as to focusing just on languages/parsers? Maybe something like ? 


Jan 14, 2013 at 11:50 PM

This is an excellent book, and in fact the one that describes the advanced parser construction method used by Irony - it explains it in details. It does an excellent job of explaining LALR, better than Dragon book IMHO. But still, it's not an easy ride, warn you.

Jan 14, 2013 at 11:52 PM

Make sure you get 2nd edition, 1st does not have this DeRemer/Penello algorithm that Irony uses.

Jan 15, 2013 at 12:07 AM

Just wrote a 5-star review for this book - I owe it to these guys. Enjoy it too as I did.

Jan 15, 2013 at 2:12 PM

And then this: