Not an issue: compilation to Robot and other machine libraries

[brucou]

Congrats on the new DSL! It is indeed a significant improvement on the experience of writing large-enough state machines (e.g., using state machines where they do make sense). I have two questions:

• why not compile to Robot (say, a "strict mode" version of the language that does not include actors)? It still makes sense to have the small size
• how easy would it be to compile to Kingly -- e.g., another state machine library? Kingly also has a compiler to vanilla JS (zero dependencies) but from a visual language (saved as .graphml file). I am interested to see how this could be used as an equivalent textual language.

Got to look at your code anyways to see how you did it but thought I'll stop by and ask.

[edit]: Ok, I had a quick look and it seems like I should be able to reuse your parser. I should just have to rewrite the traversal of the parsed tree (ParseResult). Does that make sense to you? BTW that is terrificly well-written C code. I haven't read C in a decade, and that went like a charm even without comments :-)

[matthewp]

Yeah I do want to do other output formats in the future. Probably standalone 0 dependency would be the next thing I would do. However I want to flesh out the language a bit more and make the overall XState experience better before doing that.

If you're interested in poking around then compiler_xstate.c is what produces the XState output. It takes some understanding of the AST structure though. That's something I need to document better but it's all in node.h.

[brucou]

Yep, that is the file I had been looking up. The AST structure is not that complex, and the code is well written so I should be able to achieve my goals. But I probably should wait for the language to stabilize. Well I will still play around with it. Thanks!