| Alex Rubinsteyn 2007-05-16, 7:06 pm |
| On May 15, 11:56 pm, Joachim Durchholz <j...@durchholz.org> wrote:
> Alex Rubinsteyn schrieb:
>
>
> Ah, now *that*s an entirely different box of strings.
Well phrased!
> I was thinking you were trying to handle stuff like optional else parts.
Nope, that's the job of the optional parser:
str("if") >> expr >> str("then") >> expr >> optional(str("else") >>
expr)
>
> The result of such a "syntactic element removal parser" would be
> irrelevant, so it should be either void or (if that's impossible for
> typing reasons) a constant of your choosing.
> Whatever you do, the calling parser should not expect the skip parser to
> return a value. If your framework does not properly handle that case,
> you probably have to rework it in this area.
I've settled on skip(...) return a void parser. This bypasses the
messiness of arbitrary constants.
> One implicit parameter and result of any parser is the read position in
> the input string. If you include that in the parse result (possibly just
> as a mental exercize), this may help you see the overall structure better.
> (Returning the ending position of a parse is a good idea anyway. You
> need it for all kinds of activity beyond parsing, such as generating
> error messages or beautifying code.)
The return type of a parser is a struct called ParseResult which
contains the parse state (did it match or not?), the value parsed and
a cursor to where parsing stopped. The latter is useful for
backtracking, which my parsers tend to a lot of.
Thanks for the advice,
Alex
|