Revisit inconsistent true/false/null vs literal behaviour

[ErisDS]

Currently, there's a single commented out test in the 'Initial commit' PR:

https://github.com/TryGhost/GQL/pull/2/files#diff-40ba893e5d10c536e8f08afc0dceb9e6R84

Currently the Lexer treats true_thing as a literal, but true-thing as a true, a not and a literal. This slight inconsistency is somewhat annoying, and could be considered to be a bug, however I'm not sure how/if it can be mitigated and whether it matters enough to spend time on.

Note: surrounding both in quotes results in them correctly being treated as a string value - the string form should always behave slightly better than the literal form, I think that's to be expected?

Do we document that including true, false or null in literals is bad form / may have unexpected results, do we change the lexer to reliably treat these values as bad when in a literal, or is this a kink that can be ironed out?

[ErisDS]

As shown in TryGhost/Ghost#6247, this also affects numbers (of course it does, derp).

This results in tag:2015-test being treated as a property followed by a number, a not, and a literal which then cannot be parsed.

@halfdan I think you were looking into this at one point. I'm trying to dream up a new design for the lexer.

Essentially, I think what's needed is some way to introduce the concept of a greedy match. I'm not sure how that might be possible, I've done a bit of googling and turned up some interesting writing about a similar problem with regular expression literals if you try to write a lexer for JavaScript: http://cjihrig.com/blog/creating-a-javascript-parser/, I need to read around a bit more yet and would very much welcome any input.

[laran]

#17 supports date values as literals. Hyphens are no longer special characters. One of the reasons I used ! for negation instead of - is because of how common - is, especially in things like slugs and urls. true-thing and true_thing are also interpreted as literals. Only true (case insensitive) is interpreted as the boolean true. Likewise, the literal null is interpreted as actually null.

[kirrg001]

GQL was replaced by NQL.

This issue is now tracked here. Please leave any comments over there.

[ErisDS]

Hey @laran, I wanted to update you on what happened here.

We've re-written GQL as NQL, taking on board many of the ideas that you shared in this PR, particularly the use of Mongo query JSON as the intermediary format.

NQL is split into the language parser from NQL -> Mongo JSON, and a separate tool mongo-knex that does the DB translations. We also use mingo for performing queries on JSON objects.

The new tool is significantly more robust, covers many more cases, and more powerful. It should also be useful to more projects than just Ghost. There are still some features which we haven't implemented, but we hope that with the new split concerns it will be far easier to work on them.

I know it was a loooong time coming, but thank you so much for all the work you put into this PR and to sharing your ideas with me. It was truly inspirational, and has helped to make Ghost much more powerful.

[laran]

Hi @ErisDS. This is super cool! I'm so glad that I was able to help in some way. Best of luck to you and the team!

[ErisDS]

Just realised I did not write this on #17, but hopefully you knew what I was on about anyway 😬