Some programmers avoid regexes in some situations (see this popular @nickf comment), perhaps using a parsing framework such as Lex/Yacc. Others prefer to stay within PHP, perhaps using regular expressions, as it avoids the need for another framework.

When must we use a "real" parser generator instead of coding a parser directly in PHP?

What is the best PHP tool-kit for parsing complex things and what factors can help me determine which is the best?

As I mentioned earlier, perhaps there is no best solution, but simply good practices to help select a solution.


Read below only if you is a answer writer

My question was edited: now have good english and objectivity (!), thanks a lot for @FrustratedWithFormsDesigner, @gnat and @Matt. But, perhaps with @Matt editins, losted my point of view.

  • My point is not a "Regular expressions vs. framework" dichotomy (!).

  • I think (and see examples) that programming PHP, we have a good "tool kit", not only with regular expresions (see the power of preg_replace_callback), strings functions, etc., for simple or very specific parsing tasks; but also with XML Manipulation, for complex tasks! See de "parsing power" of process with DOM and/or XSLT...

  • I see also cases where I have a dilema about use this "PHP native tool kit", or install and learn about some external paser generator (plugged as a library, or a class, etc.).

  • 1
    Ideally, one flags a question for moderator attention to migrate it to another site rather than reposting it. This keeps connections between the questions, comments and similar between the two and reduces redundancy (we're all about DRY).
    – user40980
    Commented Mar 14, 2013 at 15:01
  • Possibly related: stackoverflow.com/questions/7553722/… Commented Mar 14, 2013 at 15:08

1 Answer 1


Regular expressions vs. framework (in the sense of being separate from a language) is a false dichotomy. Counter-example: parser combinators. These can easily handle regular, context-free, and context-sensitive languages; nice libraries exist for them in many languages. Major advantages are that language integration allows them to snarf their host languages's features (such as type system, unit-testing framework, using classes/objects/functions to extend them, composability), and fewer limitations such as token lookahead; major disadvantages are that an implementation is tied to a specific language (duh), decent error messages are often difficult to generate, and they can easily be inefficient if care isn't taken.

Here are the factors that I look at when deciding what tool to use to parse something:

  • level of the language, and of the parsing tool, on the Chomsky hierarchy. Is it a regular language? Is it context-free? Is it context-sensitive? If it's context-sensitive, I'd better make sure my parsing tool can handle it.

  • testability of parsers, including those for sub-rules. It's pretty easy to build parsers that look right but are totally wrong. Being able to independently test sub-parsers makes it far, far easier to get the whole parser right. This goes hand-in-hand with composability: building big parsers by putting small parsers together.

  • whether the language is ambiguous. Some languages are ambiguous, and some tools can't deal with them. If there are multiple valid parses, I probably want to be notified of that, possibly by an error or multiple results, instead of just getting a single parse and thinking it's the only one.

  • control over parse results. What output do parsers produce -- a concrete parse tree? Are the nodes strongly typed or stringly typed? I find it very useful to have some control over how the parse tree is built, as it is being built; having to post-process the tree is often more painful and error-prone, in my experience. An example is an integer parser -- should it return an integer or a string?

  • efficiency. I don't know a whole lot about this, but there are definitely differences between different approaches, especially when there's a lot of backtracking.

  • error reporting. At the very least, parse errors should be reportable with position and current rule information; a trace can also be useful but I haven't really seen any decent solutions to this problem (although I bet there are some).

  • expressivity of the parsing tool. Does it make me jump through hoops to express simple things like a sequence of values separated by commas, with no trailing comma? I'm a big fan of BNF, but not being able to extend it is frustrating, and can make grammars look far more complicated, and thus harder to maintain, than they actually need to. Being able to capture patterns and abstract over them shouldn't be a luxury, but a requirement.

  • Sorry, my comment at my question was deleted (!)... I edited adding a NOTE. I think you show important clues, and a good checklist. Do you used XML tools? As a practical view point, when is better a "non-native framework" and when is better XSLT, XMLDOM, PCRE, etc. of "native PHP"? Commented Mar 14, 2013 at 18:52
  • @PeterKrauss my apologies for misunderstanding your question. Unfortunately, I still don't understand it.
    – user39685
    Commented Mar 14, 2013 at 18:56
  • Hum... Ok, sorry... And thanks for your effort in "fine tuning" for understand my question (!). I will to try a summarization: When the better is to use "pure PHP" (native parse libraries and parsing tools) and, When is better to use a "parse framework" (external)? -- then, if some better case, What framework(s) would you suggest? Commented Mar 15, 2013 at 14:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.