Fix a few more typos

[regexident]

This PR fixes …

• a couple of typos in the documentation comments
• a typo in InitializedStatemachine<T>, renaming it to InitializedStateMachine<T>

[mdeloof]

Thanks! Just curious, are you actively using statig? I'm always interested to hear someone's thoughts or feedback.

[regexident]

Just curious, are you actively using statig?

Not yet, but I'm working on a personal experimental Arduino-based Rust project right now where I'd like to try statig. I'll make sure to open issues (or preferably pull-requests) if I find any short-comings.

What are you using statig for if I may ask?

I'm always interested to hear someone's thoughts or feedback.

I had been working on a statechart crate of my own on and off for a while, eventually hit a barrier where I just couldn't figure out how to do transitions from sub- to super-states while also keeping things modular and composable and then eventually basically abandoned the project. So when I stumbled upon statig (né stateful) I was very happy that somebody else figured how to build a no_std-enabled zero-allocation hierarchical state-machine that's also reasonably light on boilerplate, as that had been the goal for mine all along.

[mdeloof]

What are you using statig for if I may ask?

Mostly for personal embedded projects at the moment, some of which I'd like to publish in the future to serve as examples. At work though it's still mainly C/C++, but hopefully that starts to change and I can use statig there as well.

... do transitions from sub- to super-states while also keeping things modular and composable ...

I also struggled a lot with this. Most approaches just went nowhere or became so bloated with boilerplate that it would lose all usefulness. I'm pretty happy where statig ended up, though I still wish I could get rid of the macro's. It's possible to use statig without them, but they make the developer experience just so much nicer.

[regexident]

Mostly for personal embedded projects at the moment, some of which I'd like to publish in the future to serve as examples.

Still to early to make a judgement call, but so far statig has been quite nice to work with in this embedded project I'm starting to use it in.

I also struggled a lot with this. Most approaches just went nowhere or became so bloated with boilerplate that it would lose all usefulness.

My statechart project was also drowning in boilerplate and the procedural macro logic also went through the roof.

My project was using a dedicated DSL, which I should have abandoned as it ended up making things so much more complicated:

machine!(
    machine: MyMachine {
        states: [ MyState ],
        events: [
            MyEvent {
                transitions: [
                    MyState -> MyState,
                ],
            },
        ],
    }
);

The reason for going with a high-level DSL was that I ultimately wanted to also allow for generating corresponding TLA+/Alloy models, as well as the corresponding Rust code from the same FSM definition. I was overly focussed on ensuring that the generated FSM API would not allow you to perform any transaction that wasn't explicitly defined in the DSL, which ended up suffocating me by the sheer number of specialized one-off Response enums per (hyper-)edge.

I'm pretty happy where statig ended up, though I still wish I could get rid of the macro's. It's possible to use statig without them, but they make the developer experience just so much nicer.

It's always nice to reduce the need for macros, but I have to say I found the macros in statig to be very reasonable to use so far.