Flexscript is a proprietary embedded language used in only one application, so it's completely lacking third party tools for code analysis, generation, and transformation. The first step to allow users to create such tools is to allow them working with the abstract syntax tree directly.
There are several acceptable solutions:
- publish a Flexscript parser as a standalone tool or a C++ library; it's the most convenient solution to build third party dev tools.
- implement the parser API within the Flexsim environment; Flexscript Arrays and trees are both sufficiently expressiveto represent an AST of the language.
- publish Flexscript grammar (and let the others write a parser).
Optionally, it would be nice to have an official Flexscript formatter which may take an AST and emit a well formatted Flexscript code. Sort of like clang-format for C++, or gofmt for Go.
Benefits of giving a parser to the users:
- Coding guidelines can be more easily enforced. Deprecated code can be safely replaced with the newer constructs, code formatting becomes a non-issue.
- Code generation becomes much easier and less buggy. Concatenating strings is not how code generation should be done in the 21st century.
- The model and code analysis becomes a possibility. Generating a model call graph. Detecting structurally identical repeated code blocks. Tracking the extent of the side effects. Eliminating dead code. Lots of cool things to do.
- Language-aware refactoring and code transformation becomes a possibility. Right now the only refactoring tools we have are manual search and replace, and, thankfully, regular expressions.
- Eventually, Flexscript may get support from the third party development tools too.
