[plt-scheme] feedback on monadic parser combinators implementation/translation trial and application

From: YC (yinso.chen at gmail.com)
Date: Wed Jan 6 18:56:00 EST 2010

Sigrid -

On Wed, Jan 6, 2010 at 10:01 AM, keydana at gmx.de <keydana at gmx.de> wrote:


> For the first part, the main question for me was how to represent the parse
> results, which in the Hutton & Meijer article are lists of tuples. I chose
> to have lists of a struct parse-result with fields "value" and "remaining".
>

This is similar to my choice.  Take a look at bzlib/parseq/input.ss.  I also
tried to directly port Hutton & Meijer but I didn't want to maintain all
possible parses, so I moved away from the list representation and the plus
operator.


> Another question during coding was whether I'd encounter problems by not
> using a lazy language - I didn't, but I'm still wondering whether I missed
> something :-;


AFAIK laziness will not cause parsing issues - many parsers are written in
non-lazy languages.


> For this specific application, I wanted to parse an input file and end up
> with an output suitable for loading the transactions into a program like
> Excel (for an imaginary accountant to use).
> So I didn't want to get out a string, but  structured and verified output,
> which I did by possibly "misusing" the bind operator to perform other
> operations than parsing:
>

Parsers are functions and hence you can have them return anything as long as
their callers knows what to expect.  Scheme is a dynamically typed language
- so take advantage of it ;)

Also - feel free to use bzlib/parseq to build your DTA parser.  I would be
interested in your feedbacks.
Cheers,
yc
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/users/archive/attachments/20100106/3036375a/attachment.html>

Posted on the users mailing list.