[boost] [Spirit] Possible regression (certainly a behavioural change) regarding sequential-or with optional rhs

Subject: [boost] [Spirit] Possible regression (certainly a behavioural change) regarding sequential-or with optional rhs
From: adam.butcher_at_[hidden]
Date: 2012-05-29 08:49:29

Hi Hartmut, Joel,

It seems that the new optional-collapsing behaviour in Spirit 2.5.1 overly 
simplifies the attributes of certain productions, transforming a tristate 
'optionality' (optional<optional<S>>) into a simple boolean (optional<S>). 
 This effectively flattens the two 'omitted' states into one -- in some 
cases (the use case below for example) they need to be distinguished 
(unless there is a better way to specify the rule).

Ref our previous discussion on this (
http://lists.boost.org/Archives/boost/2009/12/159680.php):  (in fact it is 
exactly this example that is causing us the problem with the latest 
version).

Adam Butcher wrote on 2009-12-04 at 13:19:51:
> [snip]
> The [array subscript] 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)? 

The attached program demonstrates the issue.  With boost 1.47 (2.5) it 
works fine, with 1.48 (2.5.1) it breaks.

I've attached the source file but included the comment at the top in this 
mail for convenience.

Kind regards,
Adam

// Change of behaviour in Spirit 2.5.1 regarding collapsing optionals
// in sequential-or productions.
//
// Previous discussion from 2009 related to this:
//    http://lists.boost.org/Archives/boost/2009/12/159680.php
//
//
// Given the STDIN
//
//    s[:]
//
// the program below is expected to produce the following output:
//
//    Have range spec...
//    No begin specified, using container begin.
//    No end specified, using container end.
//    Got: 'Range[B:E)'
//
// However, with 2.5.1, it produces the following:
//
//    Have range spec...
//    No begin specified, using container begin.
//    Have range end ''
//    Got: 'Range[B:)'
//
// 2.5.1 also fails with the simpler STDIN:
//
//    s[7]
//
// the program is expected to output:
//
//    Have plain index 7
//    Got: 'Index[7]'
//
// but with 2.5.1 it outputs:
//
//    Have range spec...
//    Have range begin '7'
//    No end specified, using container end.
//    Got: 'Range[7:E)'
//
// This can be remedied to an extent by switching the #if 1 below
// to be #if 0 enabling the collapsed optional code; however this
// makes the presence of range-end indistinguishable from the
// presence of a range-spec.
//

-----------------------------------------------
This email and any attached files contains company confidential information which may be legally privileged.  it is intended only for the person(s) or entity to which it is addressed and solely for the purposes set forth therein.  If you are not the intended recipient or have received this email in error please notify the sender by return, delete it from your system and destroy any local copies.  It is strictly forbidden to use the information in this email including any attachment or part thereof including copying, disclosing, distributing, amending or using for any other purpose.

In addition the sender excludes all liabilities (whether tortious or common law) for damage or breach arising or related to this email including but not limited to viruses and libel.