FSL: A programming language to make complex finite state machines easy to create

• fsl

  3 9 1.8

  Finite State Language specification

Yes. ♥ Target compilers for languages and other FSM libraries are a core goal, and I believe this is probably the single most important thing my language needs (comparables in portable external hooks and user-defined state datatypes.) I want the frontend and backend (and the database and the PaaS and the orbital weapons platform and the barbeque) to run the same machine, even when they aren't the same language.

A bunch of these, and some I haven't listed yet due to sloth, are already implemented and just not published yet because they're not satisfactorily tested, and because I still don't know what I'm doing about portable hooks

https://github.com/StoneCypher/fsl/issues/418

https://github.com/StoneCypher/fsl/issues?q=is%3Aissue+is%3A...

https://github.com/StoneCypher/fsl/issues?q=is%3Aissue+is%3A...

There are, actually, things like what you describe already - SMC, Canopy, and Ragel, by example, and depending on how you look at it, there's sort of an argument for Drakon and some others. I'm making mine because they don't fit my needs, but if you need something right now, they're options.

SMC is probably the best of those in my opinion. It reaches 14 languages including most of the stuff you'll actually want, is durable, near-zero-bug once you learn what it means by its phrasings, reasonably fast, and does mostly everything you're likely to want in practice. It is entirely adequate from basically every angle, something very few state machines can say (mine cannot.)

But also I'm hungry for users, so please try mine and let me know how you think I could improve. I believe that my ease of use characteristics are pretty nice, and my opinion is that ease of use is probably the Genuinely Big Barrier to fsm usage.

My opinion is that mine is simple enough that people who don't know these things can often see the value. To me, that seems important.

  import { sm } from 'jssm';

• xstate

  60 26,119 9.6 TypeScript

  Actor-based state management & orchestration for complex app logic.

  

• SurveyJS

  surveyjs.io sponsored

  Open-Source JSON Form Builder to Create Dynamic Forms Right in Your App. With SurveyJS form UI libraries, you can build and style forms in a fully-integrated drag & drop form builder, render them in your JS app, and store form submission data in any backend, inc. PHP, ASP.NET Core, and Node.js.

  

• jssm

  16 300 7.8 JavaScript

  Fast, easy Javascript finite state machines with visualizations; enjoy a one liner FSM instead of pages. MIT; Typescripted; 100% test coverage. Implements the FSL language.

So the thing is, FSL isn't released or announced. You're actually meant to be looking for the main implementation, `jssm`, which has been out for seven years. FSL is the new re-bake I started a year ago, and haven't gone public with yet.

https://github.com/StoneCypher/jssm

It's under the github link under libraries

I added some top material to the site to make what's happening clearer

• jssm-viz

  2 22 5.7 TypeScript

  Visualization of JSSM machines using viz.js

JSSM has JSSM-viz.

https://github.com/StoneCypher/jssm-viz

If you just want one to use, rather than to embed in your own software, The thing everyone's calling a live editor is actually the JSSM-viz demo. You can use that

https://stonecypher.github.io/jssm-viz-demo/graph_explorer.h...

It's kept outside of the main repo because, like xstate's, it's built on a transcompile of graphviz called viz.js, which is made with emscripten

It's several meg, and not many people want visualization, so I keep them in separate packages

You can get the graphviz code by hitting "dot" at the top, if you want to customize in ways the language doesn't know

Suggest a related project