Re: BIND Issue

I support the below proposal, with a couple of questions:

1. Are there any test cases that would be affected?

2. Do we know if this change would satisfy the commenters?

thanks,
Lee

On 8/21/2012 7:45 AM, Andy Seaborne wrote:
> This is a brief summary of the BIND comment from Holger and Jeremy.
>
> {
>    GRAPH ?g { ?s ?p ?o }
>    BIND(?o+1 AS ?o1)
> }
>
> In Query/3LC, BIND operates on the proceeding basic graph pattern, and 
> there is always a BGP, although sometimes it's empty (and invisible in 
> the syntax).
>
> This design means the introduced variable is minimally constrained by 
> scope rules because the resulting expression is joined with the 
> overall group elements.  The scope restriction of the applies only to 
> the BGP.
>
> This use of ?o1 is OK:
>
> {
>    ?s :p ?o1
>    GRAPH ?g { ?s ?p ?o }
>    BIND(?o+1 AS ?o1)
> }
>
> But there is an impact on the expression side of BIND - the scope of 
> the ?o is reduced to the BGP as well.  So it is undef in the example.  
> The ?o is the GRAPH is not available until after the BIND is calculated.
>
> In 1LC and 2LC BIND was translated to the algebra in the group pattern 
> processing:
>
>     If E is of the form BIND(expr AS var)
>         G := Extend(G, var, expr)
>         End
>
> making the restriction scope of the var the whole of the preceding 
> group up to that point and the same scope for the expression.  The new 
> var and the expression scope will be the same in any design.
>
> Filters still apply to the group but otherwise this is like writing a 
> sub-SELECT (if we allowed * to be used like this:)
>
> {
>   { SELECT * BIND(?o+1 AS ?o1)
>     {
>       ?s :p ?o1
>       GRAPH ?g { ?s ?p ?o }
>     }
>   }
> }
>
> In 3LC, it is handled before that where BGPs and property paths are 
> sorted out.
>
> Proposal:
>
> Restore the approach of the formal section of 1LC and 2LC.
> Clarify in the description section.
>
>     Andy
>
> .
>

Received on Tuesday, 21 August 2012 13:24:33 UTC