boost spirit for antlr for qif parse?

[Larry Evans]

gnucash@cbbrowne.com wrote:

>Larry Evans wrote:
>
[snip]

>Both of those parsers are written in totally different languages from those 
>used for GnuCash.  It would be equally appropriate to propose parsers 
>requiring reimplementing GnuCash in Objective CAML, Java, or Ada.
>
c++ is not as inappropriate as Java or Ada. After all, the current
qif-import files use c code and c++ can certainly do the same with hardly
any effort.

>
>In any case, the challenges in parsing QIF files would not be addressed by 
>looking into a full-scale LALR-1 style parser.  The "complexities" of QIF 
>could more than likely be fully plumbed with nothing more sophisticated than 
>FLEX.
>  
>
Can FLEX handle the type of ambiguity handled by parse-number/format?
Wouldn't some back-tracking be required in case decimal radix was tried
and found not to work? The "dynamic parsing" shown at the post:
http://aspn.activestate.com/ASPN/Mail/Message/1396631
reminded me of the parse-number/format. After all, you could parse
a number with either "comma" or "decimal" radix and decide whether
it was ambiguous similar to the way it's currently done in the calls to
check-and-parse-field in qif-parse-fields in qif-file.scm.