Re^2: Parse::RecDescent: problem with grammar and error reporting

Yeah, I started out with something like this. Then I added provisions for embedding images, literal TeX syntax that could extend to more than one lines, inlined gnuplot scripts, etc., and it became pretty much unmaintainable.

But you are perhaps right, I should at least have a go at refactoring the existing script using idioms I'm familiar with, before I jump into rewriting it with a tool I don't know (P::RD).

Comment on Re^2: Parse::RecDescent: problem with grammar and error reporting

Replies are listed 'Best First'.
Re^3: Parse::RecDescent: problem with grammar and error reporting by locked_user sundialsvc4 (Abbot) on Jan 20, 2012 at 14:25 UTC
Not so fast. (IMHO...) It does not take very long for code such as this, that is written without P:RD, to become very unmaintainable. P:RD takes what you already know (regular expressions ...) and puts them into a very complete framework that otherwise you would have to build yourself. It rather sneaks up on you ... suddenly there is some little twist on the format that you need to support, and something inside your lovingly-fashioned code goes, “snap.” Ugh.™ P:RD does take some time to get to know. (One thing that I quickly discovered is that you need to write a package of helper subroutines that you can `use` within the body of your generated grammar, so that you do not repeat yourself. Grammar handlers should be short, should of course include `use warnings; use strict;`, but generally should leverage code that is `use`d, not embedded verbatim.) But, having spent the time to learn it, I find that I use it constantly. Even “simple” requirements tend to grow, and it is not pleasant to discover that you have run out of tool. With P:RD, that will never happen.

Replies are listed 'Best First'.

Re^3: Parse::RecDescent: problem with grammar and error reporting
by locked_user sundialsvc4 (Abbot) on Jan 20, 2012 at 14:25 UTC

Not so fast. (IMHO...) It does not take very long for code such as this, that is written without P:RD, to become very unmaintainable. P:RD takes what you already know (regular expressions ...) and puts them into a very complete framework that otherwise you would have to build yourself. It rather sneaks up on you ... suddenly there is some little twist on the format that you need to support, and something inside your lovingly-fashioned code goes, “snap.”

Ugh.™

P:RD does take some time to get to know. (One thing that I quickly discovered is that you need to write a package of helper subroutines that you can use within the body of your generated grammar, so that you do not repeat yourself. Grammar handlers should be short, should of course include use warnings; use strict;, but generally should leverage code that is used, not embedded verbatim.) But, having spent the time to learn it, I find that I use it constantly. Even “simple” requirements tend to grow, and it is not pleasant to discover that you have run out of tool. With P:RD, that will never happen.