Type System support

[allan-simon]

I'm a new comer to Lua so please forgive me if my question is naive

Currently with concord the main productivity issue I have is that it does not play nice with type checking and autocompletion as it's all very dynamic.

I would like if some people managed to have some static type checking working and if so, how ?

[flamendless]

One can put comments in the source code to annotate it in emmylua or sumneko lua lsp formats

[allan-simon]

@flamendless thanks for your quick answer, but how does it play with components ?

as far as I see how to use it with simple types, I fail to see how to do it with compentns, in other languages one would say that if your system's pool has "movable" "haslifepoint" then the resulting entities are a union type "moveable+haslifepoint" and so the static analyser/autocompletion will know it has correspondent fields of these two components

[pablomayobre]

No unfortunately there is no type system that supports "generics" or the features required to type components in such a detail, so it's really hard to guarantee the types of the components.

We could do something like watch the files for changes and generate new types as you define the components but that feels extremely hacky. We will see what we can come up with.

For now we are working on a Sumneko annotation through comments as suggested by @flamendless but all components will get a "Component" type and you will need to cast it to get more detailed types (eg.: --[[@as Movable]])

[pablomayobre]

Okey so here is the idea that @Keyslam is working on:

Step One: Example code

Write a very small game with a few Systems and Components using most of Concord APIs.

Step Two: Annotations

Figure out all the annotations we need to add to allow the important parts of the code to be properly typed.

Step Three: Reduce

Here we try to figure out an ergonomic way to write the minimum number of annotations needed to then generate the annotations we wrote in the previous state.

This step involves experimenting with different annotations and what feels right, we would be writing our own DSL in the shape of comments in the Lua code, parsing it and generating new code for the LSP to process.

For this step we would be writing a plugin for LuaLS.

Step Four: Future work

Can we then generate and offer code autocomplete for writing all the boilerplate based on types provided by the user?

[wiredmatt]

Have you guys considered teal?

[wiredmatt]

A pretty fine workaround, using @class, @field and @type. Not a bad DX at all, pretty much the same as writing JSDoc

Maybe the user could have a VSCode extension / CLI utility that watches project files and looks for ECS.Component("...") calls, and generating an annotations-only file for you, following what's in the params and body. Or even better, the tool could guide you to generate the annotations themselves first, everything should be dumped to an annotations-only file. Would be nice to have the same for systems but I assume that's way harder to achieve.