Monthly Archives: September 2011

In my previous blog post, I discussed how recursive-regex has been
maturing but that it still wasn’t and was not intended to compete with
actual parser toolkits. I wanted to quantify this assumption and
present a head-to-head analysis of using recursive-regex vs usingcl-yacc.
I chose cl-yacc because
I already had a working css3-selector parser implemented. My
existing cl-yacc implementation is based on
the published
CSS3-Selectors Grammar (but the modified some to get it to work).

CL-YACC Parser

I found implementing the parser in cl-yacc to be fairly tedious,
time consuming and error prone, even for such a small language as
css-selectors. It doesn’t help that I tried to do it using the
published css3 grammar and lex files which are somewhat awkward (eg:
open parens are in the lexer and close parens are in the grammar).

I wrote a not very well documented (f)lex file reader to read in theexisting CSS3 flex
file and build a lexer compatible with cl-yacc. After getting a
valid lexer, I started working with the published grammar to convert
it to a format cl-yacc would approve of. Along the way I was finding
the syntax for cl-yacc to be pretty cumbersome, so I used some
read time execution to turn forms like the first below, into forms like
the second (macro expanded) one below which are valid cl-yacc
productions. (This is not a great idea or great code, but it did simplify
the parser def for me.)

The difficulties I had in implementation were mostly concerning where
white space could appear, in which productions, at which levels in the
grammar. It seemed like it was quite a task to get an unambiguous
grammar and have all my extra unimportant white space everywhere still
be parsable. After I had finally managed to rid my grammar of
reduce/reduce conflicts, I was able to parse my language and it seemed
like a fairly peppy parser.

The only problem I really have with this implementation is that it
seems like it is totally illegible after the fact. Even knowing about
parsers and having written this one, I don’t feel comfortable
modifying the language. It seems like it would be difficult to get
working again. Thankfully, I don’t anticipate having to do much
language rewriting in this case.

CL-YACC parser definition (lexer not shown)

(yacc:define-parser*css3-selector-parser*(:start-symbolselector)(:terminals(:|,|:|*|:|)|:|(|:|>|:|+|:|~|:|:|:|[|:|]|:|=|:|-|:S:IDENT:HASH:CLASS:STRING:FUNCTION:NTH-FUNCTION:INCLUDES:DASHMATCH:BEGINS-WITH:ENDS-WITH:SUBSTRING:integer))(:precedence((:left:|)|:s:|,|:|+|:|~|)))(selector#.(rule(or-sel)or-sel))(or-sel#.(rule(comb-sel:|,|spacesor-sel)(list:orcomb-selor-sel))#.(rule(comb-sel)comb-sel))(comb-sel#.(rule(and-selcombinatorcomb-sel)(listcombinatorand-selcomb-sel))#.(rule;; need to handle trailing spaces here;; to avoid s/r(and-selspaces)and-sel))(combinator(:s(constantly:child))(spaces:|>|spaces(constantly:immediate-child))(spaces:|~|spaces(constantly:preceded-by))(spaces:|+|spaces(constantly:immediatly-preceded-by)))(and-sel#.(rule(and-selsimple-selector)(list:andand-selsimple-selector))#.(rule(simple-selector)simple-selector))(simple-selector#.(rule(:HASH)`(:hash,(but-firsthash)))#.(rule(:CLASS)`(:class,(but-firstclass)))#.(rule(:IDENT)`(:element,ident))(:|*|(constantly:everything))(attrib#'identity)(pseudo#'identity))(attrib#.(rule(:|[|spaces:IDENTspaces:|]|)`(:attribute,ident))#.(rule(:|[|spaces:IDENTspacesattrib-value-defspaces:|]|)`(:attribute,ident,attrib-value-def)))(attrib-value-def#.(rule(attrib-match-typeattrib-value)(listattrib-match-typeattrib-value)))(attrib-match-type#.(rule(:|=|):equals)#.(rule(:includes):includes)#.(rule(:dashmatch):dashmatch)#.(rule(:begins-with):begins-with)#.(rule(:ends-with):ends-with)#.(rule(:substring):substring))(attrib-value#.(rule(:ident)ident)#.(rule(:string)(but-quotesstring)))(pseudo#.(rule(:|:|:IDENT)(list:pseudoident))#.(rule(:|:|:FUNCTIONspacesselector:|)|)(list:pseudo(but-lastfunction)selector))#.(rule(:|:|:NTH-FUNCTIONspacesnth-exprspaces:|)|)`(:nth-pseudo,(but-lastnth-function),@nth-expr)))(nth-expr#.(rule(:ident)(cond((string-equalident"even")(list20))((string-equalident"odd")(list21))(T(error"invalid nth subexpression"))))#.(rule(nth-sign:integer)(list0(if(string-equalnth-sign"-")(*-1(parse-integerinteger))(parse-integerinteger))))#.(rule(nth-sign:integer:ident)(let(extra-num)(cond((string-equal"n"ident)T);; this is because our lexer will recogince n-1 as a valid ident;; but n+1 will hit the rule below((alexandria:starts-with-subseq"n"ident)(setfextra-num(parse-integer(subseqident1))))(T(error"invalid nth subexpression in (what is ~A)"ident)))(list(or(if(string-equalnth-sign"-")(*-1(parse-integerinteger))(parse-integerinteger))0)(orextra-num0))))#.(rule(nth-sign:integer:identnth-sign:integer)(when(andinteger-1(nullnth-sign-1))(error"invalid nth subexpression 2n+1 style requires a sign before the second number"))(list(or(if(string-equalnth-sign-0"-")(*-1(parse-integerinteger-0))(parse-integerinteger-0))0)(or(if(string-equalnth-sign-1"-")(*-1(parse-integerinteger-1))(parse-integerinteger-1))0))))(nth-sign#.(rule(:|+|):|+|)#.(rule(:|-|):|-|)#.(rule()()))(spaces(:S)()))

Recursive-Regex Parser

After having written recursive-regex, I wanted a way to beat some of
the bugs out as well as have a good example of what I could use this
tool for, and with what performance characteristics. To accomplish
this task, I converted the CL-YACC grammar and lex file into a single
parser definition and
wrote some code to turn that file into the recursive dispatch functions.

REX: a recursive expression file format based (loosely) on lex

I had a really shoddy lexish reader for the existing lex based lexer.
I converted this to a similar tool (without the c blocks) for defining
named recursive expressions. These files have the .rex extension.
They consists of options, inline-definitions, and named productions.
The definitions for css-selectors are in css3.rex.

Once I had my recursive expression definition, getting the parser was
a fairly easy task. Along the way I added some code to minimize the
parse tree results by promoting children, when a parent only had a
single child that matched the same length as the parent. I also
improved the parse tracing, so that I could observer and debug what
the expression was doing while it was matching. With the tree minimized
I also had to revise many of my tests.

Performance Numbers

These are the performance numbers for the two parsers each parsing 6
short inputs 1000 times. Also included is (a version) of that
output. (Recursive-expressions return CLOS object trees that have in
the results below been converted to a list representation for easy of
viewing.) As you can see the recursive-expressions version is ten
times slower and uses twenty times the memory.

TL/DR

In conclusion, I am certainly not going to replace my working, fast,
memory efficient cl-yacc parser with my recursive-expressions parser.
However, if I wanted to have a working, legible (maybe) parser
definition, that will match as I intuitively expect, I might use
recursive-expressions. Because I am so used to using regex’s for
matching, if performance was not an issue, I would probably always
prefer the recursive expressions version. I could also see the
recursive expressions solution being a nice prototyping tool to help
develop the cl-yacc parser.

Obviously some of these opinions are going to be biased because
I wrote one of these libraries and not the other

CL-YACC

Pros

Pretty quick and very memory efficient parser

Easy to customize parser output (each production has a lambda body to build whatever output is necessary)

Theoretically well grounded

Cons

Its hard to make unambiguous grammars

Not exceedingly helpful with its suggestions for how to fix your ambiguities

Recursive Regex

Pros

Relatively easy to get working

lexer and parser are the same tool, built on top of cl-ppcre, which
you presumably already know, and has a good test environment (regex-coach, repl)

Parses ambiguous grammars

Has reasonable parser tracing built in, so debugging can be somewhat easier

Cons

Not very concerned with parse time or memory consumption

Parses ambiguous grammars

Bad pathological cases (exponential search)

Currently no architecture for modifying the parse tree other than an after
the fact rewrite

While this started as a toy, to scratch an intellectual itch, I think that this project is potentially a nice mid point between full blown parser frame work and regular expressions. Grammars are hard to get right though, so if you are writing your own language you might want to investigate something from the cliki parser generators page (eg: cl-yacc).