Re: [boost] [Spirit/Qi] Sequential-or attribute access in semantic action

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

Adam,

> > 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:
> 
[snip]
> 
> 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:
> 
[snip]
> 
> 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
http://boostcon.com