> 1. Parser.y, line 2259: is "|| (block != NULL && block->isEmpty())" really
> needed? Will block not always be null if a BlockExpr is {} (see
> StatementsAndOptionalExpr nonterminal)?
Nope, you can have a nested empty block {{}}.
> 2. Why is the OBJECT token treated specially and not mentioned in
> GeneralizedAtomicType like array/item/structured-item? Note that jn:object is
> no longer a function, as it was removed (I thought Markos removed it from
> Zorba, too). Then object should also be moved back to invalid function names.
> Suggested test: object() throws a parsing error.
I was not aware the function was removed. I've moved the token.
> 3. VersionDecl should not allow xquery in the JSONiq parser. Now, it seems to
> be allowed. A JSONiq query version declaration must be "jsoniq" (if a file
> begins with "xquery" the XQuery parser will be used anyway, so there is no way
> to test).
Yes, it makes sense. Fixed.
> 4. Why is append not authorized as a function? I thought it would be together
> with insert/rename/replace/delete.
>
> Suggested test: local definition for local:append + default function namespace
> and query append().
Fixed, but the function call can only be made through the prefixed form,
because in jsoniq you can have:
append () into ...
> 5. "From" instead of "For" is implemented, but where is "select" instead of
> "return"? (this might require discussion about getting rid of "from",
> actually. I am not sure if the from/select decision was not reverted at some
> point.)
> Suggested test: from $i in 1 to 10 select $i
"select" is handled in the scanner. There already are plenty of tests in
zorba/jsoniq. Though I think "select" handling should be moved from the scanner
to the parser if we are to allow it as a qname/function name.
> 6. Can you give me details and examples about the two new conflicts?
Which two new conflicts? The conflicts count has not changed.
> 7. How is [[]] array handled? Is it parsed as a predicate with an array
> constructor and handled in the translator?
Is it actually handled? Quite interestingly this:
let $var := [[1, 2, 3]]
return $var[[]]
segfaults in the current trunk.
> 8. TRUE/FALSE/NULL/FROM(/SELECT?) should appear in the FUNCTION_NAME rule in a
> JSONIQ_PARSER #ifdef so that they can be used as function names. Or is this
> handled somewhere else?
> Suggested test: false(), true(), null() -- from() with a local definition (see
> append above).
It is not possible to add them to the qnames because they would completely
interfere with the path expressions. One way to go around it would be to remove
the keywords from the Literals production and then check the value of the
RelativePathExprs in the rule action. It might work, but I would have to test
it.
--
https://code.launchpad.net/~zorba-coders/zorba/new-jsoniq/+merge/183640
Your team Zorba Coders is subscribed to branch lp:zorba.
--
Mailing list: https://launchpad.net/~zorba-coders
Post to : zorba-coders@lists.launchpad.net
Unsubscribe : https://launchpad.net/~zorba-coders
More help : https://help.launchpad.net/ListHelp
