Expression statements can't begin with {, even in quasi

[dan-simon]

While trying to debug

macro swap(a, b) { return quasi { my temp = {{{a}}}; {{{a}}} = {{{b}}}; {{{b}}} = temp; None } }; my w = 5; my z = 10; swap(w, z); say([w, z])

(the swap example from #194) I found that the error message seems to be due to the statement:expr token's definition being:

token statement:expr {
    <![{]>       # }], you're welcome vim
    <EXPR>
}

This causes issues in expressions like

macro foo (a, b) {return quasi { {{{a}}} + {{{b}}} } };

Where the statement expression {{{a}}} + {{{b}}} starts with { and so is not accepted by statement:expr.

This issue also occurs with objects:

{a: 2}

fails to parse.

I don't feel like I understand perl 6, the parser well enough to know how to fix this issue. I assume that <![{]> is there since we want to accept blocks (which start with {) as blocks rather than expressions, but I'm not sure.

[masak]

Thanks! 👍

Discussed this one with @sergot tonight. I think I have a proper fix for it, namely this:

@@ -64,7 +64,7 @@ grammar _007::Parser::Syntax {
         ['=' <EXPR>]?
     }
     token statement:expr {
-        <![{]>       # }], you're welcome vim
+        <!before <!before '{{{'> '{'>   # } }}}, you're welcome vim
         <EXPR>
     }
     token statement:block { <pblock> }

It passes all the tests on master.

But I'd like to (a) explain/explore why that line is there in the first place, and (b) write a regression test involving unquotes first in an expression.

[masak]

Fix uploaded as #289 — @dan-simon and @sergot, feel free to have a look when you have time.

[dan-simon]

This fix looks good to me.

We still have the analogous problem for object literals, but I don't think that can be fixed (for example, the empty object literal looks the same as the empty block). This being a problem is very rare, but it comes up in macros like

macro moo () {
    return quasi {{{
        {a: 2}
    }
}

In this case one can just surround the object in parentheses. But if we ever want, for example, object destructuring assignment, that won't work.

[masak]

Agreed about the problem for object literals. They way that problem is solved outside of quasis is with this disambiguation rule:

• If it's at the start of a statement, it's a block.
• Otherwise, it's an object literal.

As rules go, I'm pretty comfortable with this one, given that we want to avoid backtracking and given the unfortunate circumstance that object literals and blocks share a starter.

The one interesting complication is that quasis try to be "minimal" in the sense that they evaluate to the syntactically "simplest" form: a Q::Expr, a Q::Statement, or a Q::StatementList, whichever one's the first possible.

But, first, that shouldn't affect the parse at all. Having the parse be influenced by such a minimality criterion — such as, for example, choosing to parse something as an empty object literal instead of an empty block because that would make it able to return a simpler form — would not be a good idea.

Secondly, I don't know if that minimality rule is even necessary anymore, given the most recent happenings around Q::Expr::BlockAdapter. Essentially statements and statementlists can evaluate to values now, so there's less of a need to find the simplest form.