Proposal for Conditional Expressions

[michaelhkay]

Initial draft

[ChristianGruen]

Thanks, @michaelhkay, for the proposal, which I’ve discovered a bit too late (just after committing my own version, #7).

Talking about the grammar…

• I decided indeed to define the expression between the SingleExpr and the OrExpr.

Talking about the Elvis operator…

• I would vote for ?!, because it would go hand in hand with the proposed ternary conditional operator.
• Maybe we should name it null coalescing operator? As far as I can judge, the latter one is used for checking for the existence of the first operand whereas the Elvis operator is used to check if the first operand yields true (so it would rather be an operator to check for the EBV). But as you already wrote, the naming varies from language to language.

[rhdunn]

+1 for this proposal

I agree about the placement in the grammar.

In terms of usage, ?: is used as a null-coalescing operator in Kotlin, Fantom, Gosu, and Google's Closure Templates, so there is presedence for it not using a boolean check (effective boolean value). I would prefer ?: as it is more consistent with syntax from other languages, although I am not opposed to using something different like ?!.

[ChristianGruen]

so there is presedence for it not using a boolean check (effective boolean value).

That’s a good argument for sticking with ?:, I agree.

[ChristianGruen]

If we use ?: as characters, we can safely name it Elvis operator (the titling seems to be mostly related to the visual appearance of the operator).

[rhdunn]

If you have a lexer that tokenizes ?: to a single token, that will complicate parsing named tuple types with compact whitespace. For example:

declare variable$x as tuple(a?:xs:string):=1;
                             ^^-- an elvis operator token

This is solvable, as the token is unambiguous in this context as an optional indicator (?) and a colon separator (:), but does complicate the parser in this case if the lexer always tokenizes them as a single token.

[michaelhkay]

I think it would be prudent for us to attempt to pick up the grammar machinery used by the WG to verify that our proposed extensions work. Any volunteers? Perhaps we can rope in Michael Dyck who in the latter years was grammar-meister on the WG?

[michaelhkay]

Perhaps the ":" in a tuple type should be replaced by "as"?

[rhdunn]

At the moment this will not cause a conflict in the lexer. I noticed it in my plugin as I have support for the various XQuery syntax extensions and vendor extensions with tests for compact whitespace.

I would be in favour of having a way to verify the proposals w.r.t. the grammar.

Regarding using as instead of : in a tuple type, that would make sense and be consistent with the type declaration and function return type syntax.

[benibela]

JSONiq has a ?: operator for map keys. {"a" ?: b } would be {"a": b} if b is not empty and {} otherwise

Then how would {a ?: b ?: c} or {a ?: b ?: c ?: d } be parsed?

[ChristianGruen]

@benibela: Thanks for the hint. As far as I remember, there were some other discrepancies between the grammars of JSONiq and XQuery 3.1. I’m wondering if it’s possible at all to support both grammars at the same time?

[benibela]

. As far as I remember, there were some other discrepancies between the grammars of JSONiq and XQuery 3.1. I’m wondering if it’s possible at all to support both grammars at the same time?

The biggest issue is that jsoniq's [a] is xquery's array { a } and not xquery's [a]

[ChristianGruen]

Closed; see qt4cg/qtspecs#171 and qt4cg/qtspecs#170