This is an area where I happen to have some "specific Perl success stories," so let me give it a go. Several disconnected but related thoughts.
(1) First of all, you need to be comfortable with the concepts: what, conceptually, "a parser" is, and the specific role that "a grammar" has, and how it connects the "parser" with everything else that you need to do.
(2) There are many Perl modules which are essentially "wrappers" for existing parser engines which are commonly used in production compilers. In most cases, the parser is ultimately used to construct an "AST = Abstract-Syntax Tree" which represents the content and the meaning of the source-code in a form that is manageable by "the back end."
(3) But the Perl language also provides Parse::RecDescent, which is "pure Perl" and not-identical to the others. It actually constructs a Perl program on-the-fly, based on the grammar provided, and then executes it. The implied goal of the resulting program is not "to construct an AST," but to actually do something. And, once you get to know it, it is extremely powerful.
At one time in the past, I was confronted with an out-of-control client situation which involved: Tivoli® batch schedules, Korn-shell programs, and SPSS® scripts. My objective was to try to help the client make sense of what was actually going on, and to build an SQLite® database file which could be used by various tools to answer specific questions. And – "Parse::RecDescent" did it. Did all of it.
(4) "The formal syntax of" SQL and other languages is readily available online. Definitely make it your business to download these and inspect them. Even if your language is "not exactly SQL," they will illustrate how to correctly illustrate them in "grammar syntax."
<code> <a> <b> <big> <blockquote> <br /> <dd> <dl> <dt> <em> <font> <h1> <h2> <h3> <h4> <h5> <h6> <hr /> <i> <li> <nbsp> <ol> <p> <small> <strike> <strong> <sub> <sup> <table> <td> <th> <tr> <tt> <u> <ul>