I'm not entirely sure how to improve the FSM sub-language in a principled way. I'm thinking that maybe some sort of higher-order facility abstracting over FSMs could be useful, OCaml's Menhir comes to mind.

Not a huge fan of programming in the future tense :) Issue #195 seems minor to me, and probably not worth it unless there's a compelling reason. #205 seems nicer to have, but also not entirely necessary (since I solved my use-case by abstracting out the actions I wanted to take into functions)...

Not a huge fan of programming in the future tense :)

"Programming in the future tense"?

Odd -- I can't even Google that term, I thought it was more widely known. Anyway, "programming in the future tense" is writing code that could be useful hypothetically, but is not of immediate use. Future-tense code especially doesn't get the bugs shaken out of it through use, or doesn't get well thought-out because the use cases aren't entirely clear.

On the other hand, if you know the use-cases, then it isn't future-tense coding to address them.

The normie term is YAGNI.

I like PL; I think all my programming is done in the future tense.

Oh right, YAGNI! In any case, it's nice to have examples lined up of how a new feature is/should be used. That's all I'm really trying to say (badly) -- the features come from the uses.

In this specific case, I have long known that nMigen's FSM needs either enhancement or a layer on top of that to do things like constructing FSM-based streaming parsers in Yumewatari. You didn't have this context though.

As for "YAGNI", well, this works nicely with normal application code, but not when you're designing a programming language. If every feature is added in an ad-hoc way to cover the narrowest possible use case (as opposed to being explicitly fit into the big picture), you end up with something like PHP or Ruby. (Not to say those are bad languages, necessarily.)

It is true! In any case, aside from my observations of #195 and #205 I don't have much else useful to say. I'll keep writing code and if I hit something that would be nice to have, I'll add another issue.

As mentioned on Twitter, an additional enhancement that I found myself reaching for (although it may not actually be the best design) is a way to do something like this:

out = Signal()
with m.FSM(domain="pos", reset="RESET") as fsm:
    held_state = fsm.StateType() # pseudocode
    with m.State("A"):
        m.d.sync += out.eq(1)
        held_state = "B" # pseudocode
        m.next = "DELAY"
    with m.State("B"):
        m.d.sync += out.eq(0)
        held_state = "A"
        m.next = "DELAY"
    with m.State("DELAY"):
        m.next = held_state

As indicated in the example, I usually use this pattern for a generic "DELAY" state (a real use case would have a counter register as well, most likely) for use between "active" states, but it's sometimes useful in other situations as well.

This may be a Very Bad way to approach this problem but it is apparently not possible in nmigen today.

ETA: it's also odd to me that it's m.next = instead of fsm.next = to transition to the next state... could you explain why that is? What happens if there are multiple FSMs in one elaborate() method?

an additional enhancement that I found myself reaching for

Aha, I see now what you want. There is a minor issue: such an FSM is inherently harder (sometimes impossible) to analyze and transform. Right now the state variable is a hidden, local detail; in your snippet, you could easily send it outside of that module, save to non-volatile memory, etc. That means that opportunistic transformations, like using one-hot instead of straight binary, are impossible, and the encoding should be considered stable and preserved forever across nMigen versions.

That's not necessarily bad, but it's a restriction that nMigen currently does not have to observe.

ETA: it's also odd to me that it's m.next = instead of fsm.next = to transition to the next state... could you explain why that is?

It's a quirk of the current syntax. There's no fundamental reason it's done like that. It should be improved.

What happens if there are multiple FSMs in one elaborate() method?

You can change the state of the innermost FSM (relative to the m.next = statement) only.

Writing a bit more nMigen now, I can see the utility of the after_entering method. I'd also love a way to more literately express "on simple boolean condition, transition to state", rather than intermixing it with the "while in this state do this" code. Hope that's comprehensible...