[pro] Is cl-yacc going to cut it?

[Raymond Wiker]

I've used cl-yacc exactly once, and chose to implement "start
conditions" in my lexer - I use a closed-over variable to restrict the
set of patterns that I want to match in the lexer. I set and test the
start-condition in the lexer only, but it would certainly to be
possible to modify the start condition from parser rules, too.

I'll definitely use cl-yacc again, if the need arises - it's another
of those good-quality, low-profile Lisp libraries that "just work"
(tm).

[I use cl-yacc to implement a filter parser for trivial-ldap; the one
supplied with trivial-ldap is somewhat unconventional.]

On Fri, Feb 4, 2011 at 7:33 AM, Matthew D. Swank <akopa at charter.net> wrote:
> I suppose this is only marginally related to common lisp, but everything
> I'm talking about is written in common lisp.
>
> I use cl-yacc for a lot of parsing, but one thing that has always seemed
> harder than it needs to be is writing lexers to feed it. One thing that
> I've found helpful is the creation of a custom lexer for each parser
> state by making the action table entry for that state available to the
> lexer. This provides the terminals the parser is looking for, and
> narrows the tokens the lexer has to look for at each step.  However,
> this means I am also maintaining my own fork of cl-yacc.
>
> It seems (from my admittedly limited search) that this is not a common
> modification of yacc.  Before I start bugging the maintainer about my
> changes, I want to know: am I abusing yacc?
>
> I do like the separation between low level tokenization the higher level
> symbol parse, but is there another general parsing technique, available
> as a lisp library of course, that either works at a lower level than
> yacc usually does or allows the lexer to access more context about the
> parse?
>
> Matt
>
> _______________________________________________
> pro mailing list
> pro at common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/pro
>