EQL: fluent API generation

[homedirectory]

Description

Possibility of fluent API generation for EQL should be researched.

The following requirements should be consulted when considering a tool capable of fluent API generation:

1. Accepts grammar in a suitable notation (e.g., Backus-Naur Form).
   1. Supports a broad range of grammars. Should not limit input to LL form. Should implicitly
      rewrite given grammar rules if necesssary (e.g., to eliminate left recursion).
2. Generates 3 artifacts from a grammar:

   1. Java interfaces that constitute the fluent API.

      1. Ability to insert documentation into generated code (e.g., javadoc on methods).
      2. Ability to arbitrarily parameterise generated interfaces. This allows carrying of
         additional information (in the same way that EQL currently carries the entity type that is passed to select)

   2. A parser that builds an AST for a given chain of called methods.

   3. Java classes that represent the AST corresponing to the grammar.

      This requirement is closely tied to requirement 1.1 as the generated AST will have to be
      transformed into a different form that is required for EQL-specific query transformation.
      Given that EQL will be evolving, the generated AST should be as malleable as the input grammar.

3. Method calls on the generated API have acceptable compilation times. This will heavily depend on type signatures in generated methods.
4. Guarantee of correctness of expressions formed by method chains from the generated API. Any fluent API generator in Java should satisfy this property by relying on Java's type system. Therefore, this boils down to making sure that the generated API correctly represents the specified grammar.

Note that 2.2-2.3 can be viewed as extensions to 2.1. That is, having a fluent API generator that
produces the API only and leaves the parsing to the user is enough to be considered on its own.

Expected outcome

Research of possibilities of fluent API generation is conducted. The most suitable tool is chosen if there is one, otherwise it is concluded that fluent API generation is not currently possible.

[homedirectory]

• Fling
  • input format: EBNF via fluent API in Java
  • generates everything
  • - accepts strictly LL(1) grammars; consequently, generated AST has obscure structure, see Accepting a broader a range of grammars and generating an AST with closely resembling structure OriRoth/fling#24
  • - generated fluent API might be too complex in terms of type parameterisation
  • - doesn't allow generated interfaces to be arbitrarily parameterised
  • - doesn't allow generated interfaces to be documented
• Silverchain
  • input format: custom language
  • generates a fluent API only
  • + allows generated interfaces to be arbitrarily parameterised
• Flapi
  • generates a fluent API only
• javageci
  • generates a fluent API only