Closed michaelhkay closed 1 year 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…
?!
, because it would go hand in hand with the proposed ternary conditional operator.+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 ?!
.
so there is presedence for it not using a boolean check (effective boolean value).
That’s a good argument for sticking with ?:
, I agree.
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).
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.
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?
Perhaps the ":" in a tuple type should be replaced by "as"?
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.
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?
@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?
. 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]
Initial draft