Initial stubs for a Typescript WOQL AST

[hoijnet]

This is but a stub of a new typescript WOQL implementation, as a base scaffolding of a structure. It originally assumed to use the original WOQL library for rendering out the WOQL but suggest that the old WOQL be brought into the structure as part of larger rewrite in Typescript.

Some goals with this:

1. Enable the ability to persist and manipulate WOQL, including supporting stable ID:s when serialising/deserialising.
2. Enable setting WOQL component id:s manually
3. Provide a fully typed experience with Typescript, and full usability with regular javascript
4. Include parsers and generators for the various WOQL language variants: Python, Javascript (with/without WOQL. prefix), WOQL JSON AST, terminusdb cli (prolog cli datalog).
5. Preferably write the WOQL handler in a language that enables WASM usage and language portability (AssemblyScript?)

There are probably more to it, and all comments are more than welcome. The most important item for me and that started it was the ability to use ID:s as part of serialising/deserialising WOQL, but getting a rewrite done with better readability should probably be done.

Probably this should be a branch to work on together.

[coveralls]

coverage: 30.12% (+0.09%) from 30.031% when pulling 665508ec81cbea588bb08f03f9e06961f64a7068 on hoijnet:issue/refactor-woql into 1d1140212082f2805d61e8a34b887464d7909999 on terminusdb:main.

[hoijnet]

There are some fundamentals that could be good to figure out before plunging in. One of them I have been thinking of is what WOQL is.

In my mind it is two things: both a formal language with a canonical WOQL JSON AST form, expressive in natural language constructs in Javascript and Python, where nested calls in each respective language can be used to build a WOQL JSON to send to the server side.

WOQL can also be seen as a few formal language dialects: Javascript with/without WOQL. prefix, Python, and Prolog. Each is possible to see as a string to be parsed into the WOQL JSON AST directly, taking JSON expressions and parsing manually from strings. Such representations are helpful to accept partial or full WOQL queries on the web without having to use eval expressions.

The latter will need some kind of parser generator like ANTLR or some other good idea to support. I think a first target needs to improve the code of the current client, and implement support for IDs in serialisation and deserialisation of, but full language support would be an amazing thing to help people express WOQL in their native languages (for example using a wasm compiled library).

Maybe we agree on a canonical form for a text-based WOQL that is simple to write, and that can be transformed to the other forms? Maybe be realise it would be neat to have them all.

But, it would make sense to understand the priorities and tackle them in order!

[bradjonesca]

Related, also see: https://github.com/orgs/terminusdb/discussions/1996

[hoijnet]

I'm thinking of starting with a great WOQL AST API and build the rest from there. The existing woql is good enough for the moment, but a great AST experience in JS is a priority for me to start with.

Do you know of any delightful AST language APIs to review and get inspired by?

[hoijnet]

I'm closing this pull request here, this work went into the woql-ts-lib instead, at https://github.com/terminusdb-labs/woql-lib-ts