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

Subject: Re: [boost] [Spirit/Qi] Sequential-or attribute access in semantic action
From: Adam Butcher (dev.lists_at_[hidden])
Date: 2009-12-04 13:19:51

Hi Hartmut,

On Fri, December 4, 2009 5:38 pm, Hartmut Kaiser wrote:
>Adam Butcher wrote:
>> Hartmut Kaiser wrote:
>> > 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.
>
Oh right.  I had considered it desired behaviour.  The grammar spec is

    (start || (':' >> -start))

and not

    (start || (':' >> start))

I would expect optional<S> for both only in the latter case.

In the former I am deliberately allowing the specifier to the right of
the colon to be omitted -- within the already optional right-hand-side
of the sequential-or.  This allows for input such as

 (1)   $x       // $x (assume it references a sequence)
 (2)   $x[7]    // element 7 of $x
 (3)   $x[7:]   // a slice of $x beginning at element 7
 (4)   $x[:7]   // a slice of $x up to element 7
 (5)   $x[2:7]  // a slice of $x beginning at 2 ending at 7
 (6)   $x[:]    // equivalent to $x (unspecified bounds)

In the action function, wrt to right-hand-side of the sequential-or, I
need to determine:
  a)  whether a range specifier has been provided at all
      (given by (bool) at_c<1>(access_spec))
  b)  whether the range specifier includes an explicit bound
      (given by (bool) *at_c<1>(access_spec))

The left-hand-side of the sequential-or is either an (optional)
'range_begin' index if a range specifier is given or a lone 'index'
specifier if no range specifier is given.

If the two optionals on the right-hand-side were collapsed would I not
lose the ability to distinguish between (2) and (3)?

>> 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.
>
Okay.  I did have a go at recreating it but it behaved, annoyingly, as
intended.  I might have another crack at it at some point.

>> 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.
>> [snip]
>> I wondered if providing
>> identity[] for situations like these may result in more logical user
>> code.
>
> 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.
>
Yes no problem.  The implementation was attached to my original mail
but when I get the time I will have a look at adding some
docs/tests/example also.  I've been meaning to learn QuickBook for
some time -- this may be just the excuse.

Regards
Adam