Introducing “State..On” syntax to catch events makes a lot of sense. State will wait until one of the listed events happens before it process that event and continue.
Call MyFunction1(..) Call MyFunction2(...) State MyState1(MyFunction2) On Error(...) // On Timeout(...) // End
This example will test for Error, Timeout and Continue. Continue is implicit if it don’t have parameters to avoid that we need to code an empty block. State will wait until one of these three events are raised.
In the example above I only respond to events from MyFunction2 and events from MyFunction1 will be ignored. Events have a name and parameter list that is a signature. If this signature is the same for several functions we can collect events.
Call MyFunction1(..) Call MyFunction2(...) State MyState1(MyFunction1,MyFunction2) On MyFunction1.Error(...) // On MyFunction2.Error(...) // On Timeout(...) // End
In this example I respond to events from both MyFunction1 and MyFunction2. Error are processed separate, but I use the same On for Timeout. I need to think about this event collection mechanism because it also open for an error where we collect by accident.
Assuming that one of the functions have a mandatory event we should still be able to verify that this is implemented. The assembler only need to generate some kind of todo list during assembling that either is cleared or generate an error as we reach end of the module.
We already have a call instruction with a event table so it’s no big deal implementing a new instruction “State” with the same. For now I need to let this idea mature a bit and see if it hold ground.
A still have a few loose ends:
- I sound a bit inconsistent to use “Event” to catch some events and State..On to catch others.
- I probably need a “default” event to Catch unexpected events.
- I need a mechanism to Catch and Clear any event whatsoever and rules about how unprocessed events behave – I can’t have a Queue that keeps growing.
- Other Things?
to be continued in part 3