Awesome. Should we expect a tagged release with the committed-to-master fix for #66 (and if I understand correctly, corresponding 10% performance improvement in some cases?) any time soon? ________________________________________ From: [email protected] [[email protected]] on behalf of Kaspar Schiess [[email protected]] Sent: Monday, April 23, 2012 9:17 AM To: [email protected] Subject: [ruby.parslet] Status: Error message rehaul
Hi everyone, John Mettraux requested a better error reporting for the end user in [1]. Discussing his proposition, we've discovered [2] as a real bug. His original needs can be classified as an extension to parslet. I thought I'd write and let you all know where this is going. As you can see, we've largely fixed #66 (@master). Fixing it meant also saying goodbye to the @last_error instance variable in the parser. This is good and bad: Good because the error trees reflect truthfully why we aborted the parse. Bad because the reason why we abort is not always what we want to show the user. In fact, if you have BODY rule somewhere that can also just consist of opening and closing brackets (be empty), you will always interpret a misformed body as one that is empty. The parse tree that corresponds to this scenario will contain nothing about a BODY being empty, it will complain about an end statement missing after an empty body. This is what happened to John. I started work in @error_msg_rehaul to make the error reporting system pluggable. This will be my roadmap: * Make the system pluggable, implement 'Johns method' of error reporting as a demonstration. * Make the default parse be a two-phase parse: Once without generating errors, once with errors IF we fail. (see below) * Introduce syntax that allows to mark that BODY rule as somehow more important; not clear on the details there, but somewhat akin to the 'cut' in prolog, where you modify backtracking to the point of altering program flow. This should allow to improve the current error reports vastly. * This is the distant future, but perhaps: Introduce other methods for error reporting? Ideas, anyone? The second bullet will give us a speed improvement over the current engine in the order of a guesstimated 50%. This can be big. The small change to error reporting I've made this morning has won us about 10% already - clearly we're spending time in that part of the code. So the future is bright and full of rainbow colored ponies! I'll let you know, when it is here! Development will be in @error_msg_rehaul, code that is ready for release in @master. I will try to keep everyone interested involved. Discussions are welcome on this mailing list. As usual, the development will follow an open source off hours schedule and not be so fast, so don't hold your breath. I am currently starting my own company (consulting / code) and will be quite busy ;) greetings! kaspar [1] https://github.com/kschiess/parslet/issues/64 [2] https://github.com/kschiess/parslet/issues/66
