Page 1 of 1

Any nicer API around cl-ppcre?

PostPosted: Fri Jun 19, 2009 5:09 am
by alby
cl-ppcre is nice, but is there any API that wraps it in some easier-to-use syntax? I'm looking for something that'd make regexps more fluid to use, as in Ruby and Perl.

Re: Any nicer API around cl-ppcre?

PostPosted: Fri Jun 19, 2009 7:01 am
by Ramarren
I don't really see what you mean. The only significant syntax issue with regexps is character escaping (double backslashes), which is solved by cl-interpol, which has a special regexp mode.

Re: Any nicer API around cl-ppcre?

PostPosted: Fri Jun 19, 2009 8:40 am
by gugamilare
You can also use sexps with cl-ppcre to identify regexps instead of strings, which also solves the problem (and they should be much easier to memorize and read as well). As reference, see the method of CREATE-SCANNER that works on parse-trees (roll down the link I provided a little bit and you will see it).

Re: Any nicer API around cl-ppcre?

PostPosted: Fri Jun 19, 2009 9:26 am
by findinglisp
Macros, baby. You have everything you need at your fingertips already. If you're doing a lot of regex work, you typically will have a couple of patterns that you are using often and you can just use a simple macro or two to optimize the syntax for those.

That said, terse-ppcre seems to wrap cl-ppcre with a different (better?) syntax: http://code.google.com/p/terse-ppcre/

There is also cl-irregsexp which is a completely different regex implementation that claims to be faster than cl-ppcre, at least on some tests. It also has a different syntax: http://common-lisp.net/project/cl-irregsexp/ cl-irregsexp was used to build John Fremlin's fast Lisp-based web server: http://tlug.jp/meetings/2008/11/serving ... andout.pdf

Re: Any nicer API around cl-ppcre?

PostPosted: Mon Jun 22, 2009 10:23 am
by alby
Thanks all!

I had another look at cl-ppcre's API and I see that it's actually easy to use. It's just the the function/macro names are "weird" (to a Lisp newbie). In fact, I won't even have to write macros to ease things.

(Dave, thanks for the interesting links.)