expath / xpath-ng

Wishlist for XPath Syntax Extensions
Creative Commons Attribution 4.0 International
12 stars 4 forks source link

Proposal for Conditional Expressions #2

Closed michaelhkay closed 1 year ago

michaelhkay commented 5 years ago

Initial draft

ChristianGruen commented 5 years ago

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

Talking about the grammar…

Talking about the Elvis operator…

rhdunn commented 5 years ago

+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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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

rhdunn commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

@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 commented 5 years ago

. 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 commented 1 year ago

Closed; see https://github.com/qt4cg/qtspecs/issues/171 and https://github.com/qt4cg/qtspecs/issues/170