Re: [boost] Re: Optional, tie, and iterator_adaptor

From: Joel de Guzman (djowel_at_[hidden])
Date: 2003-08-31 10:59:42

Hi,

Here's another use-case...

We are working on an alternative semantic action scheme with Spirit
that will be a lot more easier to use than the current scheme. With this
scheme, the signature of the semantic action will be dependent on the
rule where it is attached to. This is similar in some sense to YACC.
For instance (I'll write in plain EBNF):

    r ::= a b c

The attached semantic-action to this rule will have a signature:

    F(tuple<A, B, C>)

Another example:

    r ::= a | b | c

The attached semantic-action to this rule will have a signature:

    F(variant<A, B, C>)

Now, unlike YACC, Spirit has iteration (kleene, plus, optional)
Here's a more or less the complete suite of patterns and the 
corresponding semantic-action signatures:

    r ::= a b    ----->    F(tuple<A, B>)
    r ::= a | b  ----->    F(variant<A, B>)
    r ::= a*     ----->    F(vector<A>)
    r ::= a+     ----->    F(vector<A>)
    r ::= a?     ----->    F(optional<A>)

Consider the comma-separated list for instance:

    r ::= item (',' item)*

This will have this corresponding semantic-action signature:

    F(tuple<Item, vector<tuple<char, Item> >)

Now consider this:

    r ::= a b? c

The action will be:

    F(tuple<A, optional<B>, C>)

It's really strange (and hard to explain) that you have to dereference
optional<B>. Example:

    F(tuple<A, optional<B>, C> args)
    {
        A a = get<1>(args);
        B b = *get<2>(args); // strange!
        C c = get<3>(args);
    }

Not only is it strange, it complexifies the code a lot when the code is
automatically generated by some meta-program. Example:

    template <class A, class B, class C>
    F(tuple<A, B, C> args)
    {
        A a = get<1>(args);
        B b = get<2>(args); 
        C c = get<3>(args);
    }

Whoops, have to do a special case IFF B is an optional!

Of all the types involved in the passing of arguments to the semantic
actions, the optional doesn't fit nicely because it is the only one
that has mixed value/pointer semantics. I am tempted to not use
optional<T> because of this and instead use variant<T, none>,
but I hate to miss the performance advantage of optional vs.
variant<T, none>. 

-- 
Joel de Guzman
http://www.boost-consulting.com
http://spirit.sf.net