Boost logo

Boost :

From: joel de guzman (joel_at_[hidden])
Date: 2001-05-21 18:13:26

----- Original Message -----
From: "Vesa Karvonen" :

> This is exactly the reason why I completely disagree on the usefulness
> point. I haven't yet had the time to analyze the spirit generator, but if
> hunch is correct, it can make implementing micro parsers an order of
> magnitude more intuitive and simpler compared to traditional methods.
> Consider, for example, the operator>> for complex presented in TCPL. The
> following is copied from the book for exposition.

Indeed, as I mentioned in my other post, I am rewriting another parser
generator (dynamic) using spirit.

Spirit reflects more the top-down parser we build by hand. Albeit
automated. The non-deterministic nature minimises the restrictions
on the grammar. One exception is left recursion which is a no-no
on LL(N) parsers. I have a way around this (by rewriting the
expression template once left recursion is detected) but I'm taken
aback because you pay for it even if you don't use it.

I wanted spirit to be small, clean and clear. The original objective
was indeed for parsing TCP/IP and thousands of protocols and more
to come every passing day, Files, Streams, and yes, small 'scripting'
interpreters. Yet I did not document that as such because I haven't
tested its scope and potential (how far it can go).

Debugging? the straightforward and intuitive nature of top down
parsers makes it very easy to follow what's going on compared
to bottom up, for example. And yes, the production rules and
expressions are all objects. Very much transparent. You can
do a stack crawl and see clearly what's going on.


Have a nice day,
Joel de Guzman

Boost list run by bdawes at, gregod at, cpdaniel at, john at