Boost logo

Boost :

Subject: Re: [boost] [Spirit/Qi] Sequential-or attribute access in semantic action
From: Hartmut Kaiser (hartmut.kaiser_at_[hidden])
Date: 2009-12-04 12:38:52


> > Well, a sequential-or is (attribute-wise) very much the same as a
> > plain sequence: a >> b. That means if you attach an action to the
> > whole thing _1 will refer to the attribute of the first and _2 to
> > the attribute of the second element in that sequence. I'll add a
> > note to the documentation making this clear.
> >
> Ah I see. So in the above snippet _1 will refer to an attribute of
> type optional<S> and _2 to an attribute of type optional<optional<S>>.
> Thanks for clearing my misunderstanding up.

Well, I expect it to be an optional<S> only as well, but I'm not sure.
Normally this kind of redundancy gets collapsed away (and there is no reason
for it to be an optional<optional<S>>.

Ok, I looked: you're right, but I consider this to be a bug. This will be
fixed in the next release, then.

> I use multi-argument sequences elsewhere so I should have really
> thought to try that (hindsight is such a wonderful thing!) In my
> experiments I had switched the '-start' for 'int_' and was convinced
> that my _1 had become 'int' by the time it reached the function --
> this is what confused me into thinking that it was the right-hand-side
> that was being delivered as _1. I assume now that this must have been
> to do with my change causing some earlier error and the compiler had
> substituted 'int' for some unresolved type which had arrived in my
> function. 'int_' was probably a bad choice for the test!

Hmmm. Doesn't sounds like it. If you ever come across this again, please
drop us a line.

> This lead me on to the following, rather pedantic, musing on the
> provision of the identity[] directive in the core library to 'flatten'
> composed attributes. In re-implementing my action function with two
> arguments I had difficultly naming the first argument as it has
> logically distinct semantics based on whether the second (range
> specifier) is provided. Previously (with identity[]) it was one
> argument named 'access_spec' and gave rise to the following
> implementation:
> In the above the first element of 'access_spec' is effectively
> unnamed until it is resolved to be either 'range_min' or 'index'.
> Using two arguments I was forced to name the first even though its
> semantics are conditional on the second. Going for arguments named
> 'range_min' and 'range_spec' gave rise to the following:
> which leans toward the range alternative -- effectively changing the
> meaning of 'range_min' in the else case. I wondered if providing
> identity[] for situations like these may result in more logical user
> code. Perhaps I just think too much -- or perhaps I should just have
> two functions to start with (though that would probably affect the
> elegance of the grammar spec)!

That sounds good to me. Would you be willing to contribute the identity[]
directive? In this case we would need some docs, tests, and an example or
two as well.

Regards Hartmut

Meet me at BoostCon

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