> While this may look like code in a normal programming language, it operates entirely differently. So happy to see this called out up-front. One of the hardest things with FPGAs as a developer is understanding that you're reconfiguring hardware instead of a series of serial asm/opcodes. They look superficially the same but have very different requirements and constraints under the hood.
It depends very much where we as developers come from. My CS degree had quite a few sections of electronic lectures. In fact, one way I always looked at function composition in FP languages was to think of them as digital circuit modules.
Combinational logic is functional as long as you keep feedback loops out of it. For a given input, you will always get a particular output. Eventually. Time is a factor.
Unlike software, this bit of functional logic is "on" or "active" all the time though. At any given moment, there is something at the input and something at the output. It's like a pair of sunglasses. They are always sunglassing, light is going through them and being filtered, whether you are using them or not.
Adding state is necessary for anything but the most trivial designs. And like software, state makes things more complicated. We call the logic that implements state "sequential" logic. By that token, instead of Combinational, we could call it Concurrent logic.
Actors could be a logical grouping of combinational and sequential logic. Pure functions and state. With ports for messaging.