DDC-1947: Update EBNF with arbitrary joins

[doctrinebot]

Jira issue originally created by user @ocramius:

Arbitrary joins need to be documented in EBNF

[SenseException]

What does EBNF mean?

[Ocramius]

@SenseException Extended Backus–Naur form

It's a notation used to describe a grammar.

[SenseException]

Currently only WITH, which is also used for the arbitrary joins in the documentation, is listed at the EBNF part of the documentation, but not mentioned in there with the name "arbitrary joins".

https://www.doctrine-project.org/projects/doctrine-orm/en/latest/reference/dql-doctrine-query-language.html#from-join-and-index-by

Arbitrary joins are mentioned with an example outside of EBNF though: https://www.doctrine-project.org/projects/doctrine-orm/en/latest/reference/dql-doctrine-query-language.html#dql-select-examples (at the bottom)

[Majkl578]

Out of sync EBNF is going to be an issue during DQL parser rewrite. I already ran into some places where EBNF and parser differ, but afaik also parser comments didn't match actual code. If you are aware of some issues, please send PR to fix those issues. 😊 I'm not sure whether ORM 3 will stick with EBNF (there is no reason to not to), but it will definitely need to be revised and synced with new parser & language definition.

[Ocramius]

I'm not sure whether ORM 3 will stick with EBNF

If we're going with the Hoa parsers, then their parser is actually generated from a BNF-alike syntax ;-)

[Majkl578]

Yup, the PP language. But EBNF is imho more readable for casual consumers. PP, and especially its namespaces, is a bit more complicated. I already have some DQL prototype in it, based on EBNF. :)

[Ocramius]

The readability issue is secondary here, IMO: having a centralized definition of the language should be the first aim. Once we obtained that, we can likely ask our @doctrine/team-orm-documentation on how to proceed.