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




Reply via email to