[Bug 27537] [XP31] Sequence on lhs of arrow operator

https://www.w3.org/Bugs/Public/show_bug.cgi?id=27537

Michael Dyck <jmdyck@ibiblio.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jmdyck@ibiblio.org

--- Comment #9 from Michael Dyck <jmdyck@ibiblio.org> ---
More explicitly, the productions:
    CastExpr    ::= UnaryExpr ( "cast" "as" SingleType )?
    ...
    PostfixExpr ::= PrimaryExpr ( ... | Lookup | ArrowPostfix )*

would become:
    CastExpr    ::= ArrowExpr ( "cast" "as" SingleType )?
    ArrowExpr   ::= UnaryExpr ( "=>" ArrowFunctionSpecifier ArgumentList )*
    ...
    PostfixExpr ::= PrimaryExpr ( ... | Lookup )*

I did a trial parser/applet build with these edits and they don't appear to
cause any problems (ambiguities or conflicts).

----

Here's the pertinent chunk of the XQuery/XPath 3.x expression hierarchy,
(where "v" can be read as "directly derives"), with the
current and proposed levels for ArrowExpr/ArrowPostfix.

    CastExpr
      v             <- proposed position of ArrowExpr
    UnaryExpr
      v
    ValueExpr
      v
    SimpleMapExpr
      v
    PathExpr
      v
    RelativePathExpr
      v
    StepExpr
      v
    PostfixExpr    <- current level of ArrowPostfix

----

Here are some example queries that will be treated differently under
the status quo vs the proposed change.

Mike's examples above [in support of the proposed change] correspond to
examples "UnaryExpr", "PathExpr 2", and "SimpleMapExpr 2".

Perhaps the strongest argument against the proposed change would be based
on the last three examples ("PostfixExpr N"), in which a query such as
    $a=>f()[1]
would become a syntax error. Instead, you would have to write
    ($a=>f())[1]
to get the effect that the former query currently has.

(Note that where an example uses a VarRef, any other PrimaryExpr would do,
e.g. a FunctionCall or a ContextItemExpr, which might make the example
more realistic.)

---------------------------------------------------------------------------
UnaryExpr:

                         - $x =>f()

currently: equiv to      - ($x =>f())

proposed:  equiv to      (- $x) =>f()

---------------------------------------------------------------------------
ValueExpr -> ValidateExpr:

                        validate {Expr} =>f()

currently: syntax error

proposed:  equiv to     (validate {Expr}) =>f()

---------------------------------------------------------------------------
ValueExpr -> ExtensionExpr:

                        (#pragma#) {Expr} =>f()

currently: syntax error

proposed:  equiv to     ((#pragma#) {Expr}) =>f()

---------------------------------------------------------------------------
SimpleMapExpr 1:

                        $a =>f() ! $b =>g()

currently: equiv to     ($a =>f()) ! ($b =>g())

proposed:  syntax error

---------------------------------------------------------------------------
SimpleMapExpr 2:

                        $a ! $b =>f()

currently: equiv to     $a ! ($b =>f())

proposed:  equiv to     ($a ! $b) =>f()

---------------------------------------------------------------------------
SimpleMapExpr 3:

                        a/b ! c/d =>f()

currently: syntax error

proposed:  equiv to     (a/b ! c/d) =>f()

---------------------------------------------------------------------------
PathExpr 1:

                        / $a =>f()

currently: equiv to     / ($a =>f())

proposed:  equiv to     (/ $a) =>f()

---------------------------------------------------------------------------
PathExpr 2:

                        / a =>f()

currently: syntax error

proposed:  equiv to     (/ a) =>f()

---------------------------------------------------------------------------
RelativePathExpr 1:

                        $a =>f() / $b =>g()

currently: equiv to     ($a =>f()) / ($b =>g())

proposed:  syntax error

---------------------------------------------------------------------------
RelativePathExpr 2:

                        $a / $b =>g()

currently: equiv to     $a / ($b =>g())

proposed:  equiv to     ($a / $b) =>g()

---------------------------------------------------------------------------
RelativePathExpr 3:

                        a / b =>g()

currently: syntax error

proposed:  equiv to     (a / b) =>g()

---------------------------------------------------------------------------
StepExpr -> AxisStep:

                        child:a[1] =>f()

currently: syntax error

proposed:  equiv to     (child:a[1]) =>f()

---------------------------------------------------------------------------
PostfixExpr 1:

                        $a =>f() [1]

currently: equiv to     ($a =>f()) [1]

proposed:  syntax error

---------------------------------------------------------------------------
PostfixExpr 2:

                        $a =>f() ("arg")

currently: equiv to     ($a =>f()) ("arg")

proposed:  syntax error

---------------------------------------------------------------------------
PostfixExpr 3:

                        $a =>f() ?key

currently: equiv to     ($a =>f()) ?key

proposed:  syntax error

---------------------------------------------------------------------------

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Tuesday, 6 January 2015 18:18:23 UTC