Obviously it's your code, you can do what you want with it! The reason I don't use treetop is because it's horribly painful to use, and I could never get a grammar to work with it. Parslet is a dream, so much of a dream that I personally never even had to use the error_tree to debug my grammars and get them working.
But if you or other users find the current error_tree useful, then of course, that's that, I'm just me. Suggestions or examples of how to provide useful end-user parse error messages with Parslet would definitely be welcome though, if anyone has them. On 4/17/2012 3:50 AM, Kaspar Schiess wrote: > On 17.04.12 04:11, Jonathan Rochkind wrote: >> If Parslet can be modified to make this easier, I'm all for it. If you have >> to choose between error messages useful for grammar developers and error >> messages useful for end-users entering strings to be parsed -- I'd >> definitely choose in favor of the end-users. > I refuse the excluded middle here. Current parser errors are what makes > parslet cool to me and to people I've been getting feedback from. If you > want an engine that is just geared towards end users - parslet is not it. > > The debugging argument you make is invalid. Treetop also generates Ruby > code and could be amended to debugging with the techniques you describe > - and it's faster too! - but I don't see you using it... > > This is a clear case of shifting needs. Need no. 1 is mine: how to debug > a parser engine? Need no. 2 is the grammar writers need, how to debug > the grammar I am writing? Need no. 3 is the grammar users need, how to > make my input conform to the grammar? > > I am all for pluggable error engines (how cool would that be!), but I > will not support either/or decisions on this one. > > My current plan is to fix the engine we have (it's broken a bit) and > then see how to make it pluggable. Then I will try to get jmettraux to > implement his strategy as a plugin. Let's see how that goes (unless > someone has a better idea that doesn't mean sacrifice). > > kaspar > > > >
