Is there any clear difference between event and state

Question

This question is a bit philosophical and is like "data and code are the same thing or not".

Is there any clear difference between event (signal) and state?

Example:

For example, there is a car passing by the road. When the car horns, a man (man_A) crossing the road stops suddenly. Horn is the signal, "man_A stops suddenly" is the state of man_A.

Another man (man_B) was crossing the road too at the same time, at the same place.

Let's consider that man_B was deaf, so he can't hear the horn. But realizing "man_A stopped suddenly" would be a signal for him. He would stop suddenly as if he heard the horn.

So I would say "A state could be a signal for another process. A signal puts a process another state. That's why they are exactly the same thing"

Am I wrong, is there a clear difference between them?

A signal is a state change. We may define any signal with two states.

Answer 1

Events and states are both considered data, yet they differ fundamentally.

An event occurs at a specific point in time. After that it is history. An e-mail is a perfect example. Once you communicate it, you can't change it anymore. All e-mails in your archive are history.

A state can change over time. As long as you are editing an e-mail, it is a state in your mail editor and you can change it at will. Once the e-mail has arrived, the receiver can store it in a stateful storage. That allows him to change it (which he will hopefully not do). But he can never change the message that was sent. In many cases, there are log files to prove it.

For this reason, states and events obey different mathematical rules. A state space can be manipulated with predicates (from predicate logic) and event streams obey the laws of trace algebras. This allows us to reconstruct a state if we know a previous state and all events leading up to that state. However, it is impossible to reconstruct the event history from just a state space.

This has an impact on how to design software. Since states can be constructed from events, the most natural way is to look at your event streams before you design an application. Then you can write application services to work with these event streams.

When I design software, I tend to have two data layers: the event layer and the state layer. In the event layer, I design the communication structure. In the state layer, I put the various databases that store the state. That works wonders in keeping the overall amount of software small and manageable.

Answer 2

They are very, very different:

• The same event may cause transitions to different states, depending on the current state:
  

• In SCXML you can have <parallel> states defining orthogonal regions. In this case a single event may trigger multiple simultaneous transitions to different states:
  

• Further, due to the possible presence of cond="…" attributes, a transition to another state may or may not occur when triggered by a an event. So now we have an event that might not change state.

• Further, it is possible to have a transition with no event attribute, causing a state change as soon as some data model value or script result is right. So now we have a state change that can take place with no triggering event.

Answer 3

Well, a state is not a signal because a signal comes at a certain specific point in time.

A state-change is a result of a signal and can be seen as a signal by itsself. But it is not the state itsself. The state continues to be after the signal is long gone.

How would the initial state be a signal, for example.