ramarren / cl-parser-combinators Goto Github PK

fare-matcher's implementation never grew beyond the stage of a proof of concept. Therefore, with my project to Consolidate Common Lisp Libraries
http://fare.livejournal.com/169346.html
I've decided to declare it dead and to have everyone use the best pattern-matching library around town, which is Optima:
https://github.com/m2ym/optima/

I've been working with the author to make sure his library will have no missing functionality as compared to fare-matcher or any other CL pattern-matching library. You may or may not be using some more advanced features of fare-matcher, such as using pattern variables as part of a guard condition (i.e. (list a (equal a))), which the author is busy adding to the library currently. If you are indeed using such patterns, please wait a few days or weeks for Optima to be fixed. Otherwise, I invite you to switch from fare-matcher to optima at your earliest convenience. In case you were using it, note that fare-quasiquote has been split into its own system, and now supports optima in addition to fare-matcher and in preference to it.

PS: please consider merging cl-parser-combinators, too, and/or splitting them into parts, some of which could be merged. I know that for instance, drewc is working on parser combinators in this SMUG library, and is currently moving them to use Interface Passing Style, which allows him to directly lift Haskell code that uses typeclasses.

Is it likely that others may find the ability of PARSE-STRING to handle sequences apart from strings useful?

 PARSER-COMBINATORS> (tree-of (current-result (parse-string (find? "bb") '(#\a #\a #\b #\b #\c #\c))))
 "bb"
 PARSER-COMBINATORS> (tree-of (current-result (parse-string (find? "bb") '#(#\a #\a #\b #\b #\c #\c))))
 "bb"

Would it be more accurate (and perhaps better advertise the potential of CL-PARSE-COMBINATORS?) to rename PARSE-STRING as PARSE-SEQUENCE or something along those lines?

I can see the rationale behind changing word?, but it took me a while to figure out why my parser stopped working when I updated cl-parser-combinators last night. Perhaps a strict-word? that is only letters, leaving the old alphanum word? in place might cause less damage?

Thanks for making your parser combinator code available. Fun stuff. I noted that FIND?, while advertised as looking for the first match, does not seem to leave the context at the corresponding point (i.e., directly succeeding the first match):

PARSER-COMBINATORS>  (tree-of (current-result 
                   (parse-string 
                (mdo (<- x (find? "aa"))
                     (<- c (context?))
                 (result (cons x (context-peek c))))
            "aabbaacc")))
("aa" . #\c)

Given the advertised behavior of FIND?, would it be preferable to leave the context at the point directly after the first match?

PARSER-COMBINATORS>  (tree-of (current-result 
               (parse-string 
            (mdo (<- x (find?2 "aa"))
                 (<- c (context?))
                 (result (cons x (context-peek c))))
            "aabbaacc")))
("aa" . #\b)

where FIND?2 is something like

(defun find?2 (q)
  (with-parsers (q)
    (mdo (<- x (breadth? q nil nil))
     (result (first x)))))

Thanks again,

Alan

Hello Jakub,

Nice work! Thanks! Could you consider include in the doc directory one or two examples of parsers using the library? That would be nice to give us a better understanding of the library. One such example could be a parser for CSV files. I am planning to use this library to construct a paser for N3 files (http://www.w3.org/TeamSubmission/n3/).

BTW, I included in the Wikipedia page about parser combinator a link to this project.

Cheers,
Alexandre

I got an error

invalid number of arguments: 3
   [Condition of type SB-INT:SIMPLE-PROGRAM-ERROR]

with (parse-string* (regex* "(\\w+)") "asdad adasdd") what am I doing wrong?

As you can see on the cl-test-grid library page for cl-parser-combinations,
http://common-lisp.net/project/cl-test-grid/library/cl-parser-combinators.html,
since quicklisp 2013-10-03 the library doesn't build on ECL lisp-to-c compiler.

If you click the failure link, you can find the build output.
The error message:

;;; Error:
;;;   in file basic.lisp, position 4783
;;;   at (DEFUN NOTE-POSITION ...)
;;;   * Syntax error in declaration ((INTEGER 0) POSN)

I don't know if the declaration is valid according to CLHS or not.
In other words, I don't know if it's a ECL bug or a bug in
cl-parser-combinators.

But the fact is, the library doesn't build on ECL now.

whitespace? calls between? with result-type being nil

This leads to an error in between? because it tries to call (coerce nil nil), which (at least on SBCL) results in an error.
Note that NIL is not really a type. Did you mean NULL (the type of NIL)?

Christian

I realise that the problem is tightly related to debugging, and has equivalent hardness,
but some profiling mechanism would be very helpful for those weak minds of us,
who are prone to producing parsers with superlinear blowout..

As you can imagine, the output of SB-SPROF is not very helpful for a fundamental reason : -)