The New Query Api (aka [1]007 with the license to kill redundant frontend boilerplate)

[EagleoutIce]

Alongside #980 i am creating a new query API which should be used to consume the following features:

• query dataflow (simply (re-)returns) the dataflow of a file #1034
• query normalized AST (similarly to the dataflow re-request)
• query slice (replaces the old slicer query, Add location based restrictions to query API #1030)
• query lineage (replaces Add additional ":lineage" command and message #915)
• query clusters (Dataflow cluster analysis #977)

This should be part of 2.1 which will start to deprecate the other messages. Comments are open until #980 is stable and in main, for now, you may refer to https://github.com/flowr-analysis/flowr/blob/980-context-sensitive-call-pattern-queries/wiki/Query%20API.md for the evolving documentation of the Query API.

As a benefit this would provide server/cli/... integration for new queries with just one definition, drastically reducing the boiler plate. Additionally, this allows the (re-) use of virtual queries like the compound query to group and pre-determine arguments!

[EagleoutIce]

Feel free to comment @SunVal, @LukasPietzschmann, @Ellpeck, @allaboutmeme.

[LukasPietzschmann]

I only have one question: did you intentionally wait until the issue could be #[1]007?

[EagleoutIce]

No, as you may see from the title change this was just a nice coincidence :D

[LukasPietzschmann]

Once #1021 is finished, I think it location based restrictions could become useful. For instance, consider the following example where only nodes originating from the test_file.R file would be included in the search scope.

[
  {
    "type": "call-context",
    "callName": "^except_.*$",
    "kind": "check",
    "subkind": "except",
    "location": [ "path/to/test_file.R"	]
  }
]

What do you think about that (as this could theoretically also be implemented client side)?

[EagleoutIce]

Thank you for the proposal, i think this should be part of the query api, but probably be outsourced into another issue, can you please create one?

[EagleoutIce]

To speedup the release of 2.1.0, we no longer schedule the inclusion of all of these messages with 2.1.0 but will do so with later releases based on the demand.

[LukasPietzschmann]

I think this should be part of the query api, but probably be outsourced into another issue, can you please create one?

Sure, it's now tracked in (or with?) #1030