I find this odd because, outside the state machine, you typically don't know what state it's in. When you send it a message to change its state, it could be in

I find this odd because, outside the state machine, you typically don't know what state it's in. When you send it a message to change its state, it could be in any state. If it's in the wrong state, you get an error. So the runtime check is inherent. It seems like this is handled pretty simply by having a class with one field that contains the enum or ADT and switch statements in each method? Compile-time checks seem to be about using the compiler to force the caller to use a protocol correctly, but even if you can do that, in any concurrent or distributed or event-driven system, you can't trust that, unless the object is somehow private or locked. (Even when parsing a file, you don't control what's next in the file so you need to report errors.) In particular, traffic lights are kind of a silly metaphor to demonstrate the need for compile-time checking, since they're public and you can't lock a traffic light. Language design needs to be driven by more realistic examples.