Reworked DSL

[jmg-duarte]

I'm currently working on decoupling the existing macro into two main "libraries": the DSL and the checker.

This approach provides more flexibility w.r.t. the DSL while keeping the checking contained.

One of the main mistakes I did when implementing the first version can be summed up as premature optimization - I was trying to cut down on passes (noob mistakes) by doing checking and generation at the same time.

I noticed that the generation part can be provided standalone, it still provides enough value an would probably address bugs like #34. It would also simplify handling things like #37 and maybe even take care of #35.

Oh, and it shouldn't require the mod for the generation 😅

Some of my loose ideas and current state of affairs below:

enum Color {Red, Green, Blue}

// the automaton attr macro adds a generic field `State` 
// which should implement the sealed trait pattern
// I don't know how to take the lessons from sealed-rs and apply them here yet 
// with more use cases maybe they reveal themselves
#[automaton]
struct LightBlub;

// maybe, by putting the #[state] here we can get more information on the state...
impl LightBulb<On> {
    // something that I really need to support for the checker is self
    fn new() -> Self {
        Self { state: On } // this sucks but I don't have a solid idea how to handle this
    }
}

// no `mod` means no context, hence, we need to help out the macro 
// by adding the automaton it belongs to
#[state(LightBulb)]
struct On {
    color: Color
}

#[state]
struct Off;

#[state] // until I follow up closer on #35, this won't change
enum MaybeOn {
    // these fields can be inferred in the simple cases
    // i.e. no generics, lifetimes and friends
    // my idea to handle those cases is simple, the user writes them by hand and the generator "ignores" them
    // the other ones is simply a matter of replacing the Unit style with State(State)
    // it would be cool if there was some type of hole that we could provide here and say 
    // "Type X will exist of exists, just replace ident with the full type"
    On, Off 
}

cc @Dessix

[Dessix]

I believe the mod may actually be a good idea still- proc-macros can theoretically link context across separate attribute invocations, but it complicates things immensely and limits either the viability of incremental recompilation or the availability of contextual information.

One thing I'd suggest changing, however, is moving the individual handler implementations into the attribute's scope, so it can use that context information in determining type substitutions.

[jmg-duarte]

Can they? How? 👀

I agree with the individual handlers and to clarify, the mod only leaves for the lite version. Which could be treated as an "assembly" of sorts to which the #[typestate] gets compiled into.

[Dessix]

Can they? How? eyes

Drop the context information into the output directory that let you side-channel the context information during execution of each annotation that relies on another one's context. Don't do it, it's awful, and is prone to "the compiler made an optimization, so now you're broken forever".

lite version

I'd argue that you're just splitting the problem into harder to solve sub-problems if you want separate light and full-featured versions. The moment you've evoked magic to transfer context between annotations, you've destroyed the simplicity that makes it "light". If instead you say the user must provide all of that context, you've increased verbosity immensely, or restricted functionality, which will echo into the implementation of the "full" version.

"assembly" of sorts

If I understand you correctly, this will further isolate the state machine from its context, making it even harder to eliminate boilerplate in the implementation.

[jmg-duarte]

I was just curious about the context transfer, I didn't intend to implement it. I knew it was possible, just not how.

The "context" the lite version requires can be achieved by making the user add more information (i.e. #[state(LightBulb)]).
In the full featured version, this can be abstracted and filled in by the main macro, given that the macro on top of the mod will be executed before the ones inside.

If you do have ideas for the syntax and architecture, let me know!