Re: [boost] Library for configuration file parsing

Subject: Re: [boost] Library for configuration file parsing
From: Dean Michael Berris (mikhailberis_at_[hidden])
Date: 2010-12-02 11:30:17

On Thu, Dec 2, 2010 at 11:55 PM, Hartmut Kaiser
<hartmut.kaiser_at_[hidden]> wrote:
>> Unfortunately I have the reverse of your experience. Parsing with a big
>> switch and implementing my own DFA for incremental HTTP parsing is so ugly
>> and unintuitive that I've had to rely too much on trial and error while
>> doing it. I long for the day when I can just define a restartable
>> Boost.Spirit based composed parser and not have to worry about the parsing
>> details -- I really want to define my parsers now in a declarative way
>> that Boost.Spirit across all the versions I've used (Classic and v2.x),
>> and hopefully that won't be too far in the future.
>
> Dean, have you seen this:
>
> http://article.gmane.org/gmane.comp.parsers.spirit.general/21109
>
> ?

Yes Hartmut, I almost jumped for joy seeing that message. I think the
universe was cooperating when my question was answered. ;)

However it still depends on Boost.Coroutine which isn't yet part of
the official Boost distribution. The last thing I want is to host
Boost.Coroutine in cpp-netlib and then make that a requirement for the
review when I submit cpp-netlib for review and inclusion into Boost.
;)

That's not such a bad thing though, but really what I want to see is
something more generic than this approach. It's very closely tied to
Asio and abstracting the input stream through a synchronous interface
-- or with continuations/co-routines -- albeit works is not really the
way I want to go.

Something that allows me to create a function object out of Spirit Qi
expressions, which in itself keeps state and can be passed around,
serialized, and is iterator agnostic, would really be what I'm looking
for. Using coroutines is cute and good for all intents and purposes,
but a composed function object parser with internal state is much more
generic and more usable in contexts other than through asynchronous
IO.

Maybe if Boost.Accumulators and Boost.Spirit hooked up and had a baby,
that'd be what would describe what I'm looking for.

I hope that made sense. :)

-- 
Dean Michael Berris
deanberris.com