Re: [Boost-users] Library Interface Design

From: Jens Theisen (jth02_at_[hidden])
Date: 2006-09-13 14:55:29

Joel de Guzman <joel_at_[hidden]> writes:

> One-phase construction definitely!

I'd like to ask you a question about your parser framework that is
related to this. I probably get most of the following wrong, so please
be patient.

More often than not, a parser constructs objects in a hierarchical
manner that reflects the grammar:

print(a + b);

might be expressed as

statement(plus_expression(symbol("a"), symbol("b")))

in some language. The latter objects are better be designed without
default constructors, in order to guarantee that we never end up with,
say, a meaningless symbol() or plus_expression().

When I write a parser by hand, that's straight forward:

boost::optional< plus_expression >
parse_plus_expression(input_tokens tokens)
{
  ...
}

The function will return boost::none if the expression can't be parsed
and no default plus_expressions will be necessary.

With spirit, there appear to be two approaches:

1) semantic actions, which store away the parsed expression in some way

and

2) closures, which implicitly "return" their first member (member1).

I don't like 1 for most purposes, because it's too imperative for my
taste. I need to keep track of what my actions did and, if something
fails to parse at a point and backtracking occurs, need to manually
revert the changes. This seems error prone to me.

2 looks better, but, and this is the connection to the OP, it appears
that the returned value, as all closure members, must be default
constructible. In particular, I risk returning such default
constructed values when I failed to assign to them.

It's very likely that I missed something, as I didn't seriously tried
using spirit. Can you shed some light on this?

Jens