Experimental Physics and
Industrial Control System
Ralph Lange wrote:
As a result of intensive (almost excessive) discussions of today, I
would like to spit out a requirement for:
Tagged unions as a basic V4 data type
Let me give one example based on the idea of implementing Sequencer
state sets as (pseudo) record instances:
The sequences will (hopefully) be able to support parametrized states,
i.e. instead of changing global variables and plainly switching to
another state, you can switch to the new state handing in some
parameters. If the current state of a state set is to be represented by
a (pseudo) field of the state set's (pseudo) record, that field's data
has the form of a tagged union, i.e. it is organized like:
state = init state = start state = wait
int i1 double d; char t1;
int i2 int j1; int j3;
Such a field can transparently contain the complete state information,
including any parameters for that state.
Structures (such as the parameter list) are represented by C structures
internally and property catalogs externally (through DA).
The state tag is represented as an enum (both internally and externally).
The DA representation of the tagged union would be a property catalog
that consists of the tag (which is an enum) and the properties that can
vary in type, name and number depending on the tag's value.
Access can be managed by generating DA code that:
- find()s only properties that are present - depending on the tag value
- traverse()s always the tag first, then the matching properties, both
for the reading and writing traversals
The only place where DA has to be extended is for the new method (under
construction) that traverses the property names and natural types. For
that special traversal, the tagged union is very much like an enum, but
with an additional property catalog connected to each of the enum
choices that can be traversed to find out the properties and types
present in that state of the union. ((Delivers a State of the Union
In other words ... A regular plain enum (functionality that is already
implemented) is just a special case of a tagged union: an empty union
with no data properties connected to the state string.
What do you think!?
I think you could certainly make a tagged union that implements an
EpicsEnum interface (although there are probably several "virtual" tags
missing from the current EpicsEnum definition that would need to be
added to do so), and I can see that the DA hierarchies might match
closely. However I think the two are *significantly* different in
internal complexity, such that it would be a major mistake to implement
an enum as an empty tagged union. Enums are very simple beasts, whereas
a tagged union needs to be self-describing, such that the generic field
view code is capable of introspecting it.
To step back a little: I don't understand why your states have
parameters, and what you could do with them - presumably I can't put a
CA monitor on a member of a tagged union (what happens to the monitor
when the state changes and the member no longer exists?). If these are
the inputs to the state machine, where do you put inputs that are needed
by more than one state?
I suspect I just don't understand what you're trying to do; I can see
some uses for a tagged union but I don't think it's vitally important
that we actually provide one - a structure containing all the members
would use more memory, but I doubt if the memory savings would be
significant compared to the code complexity.
Podiabombastic: The tendency to shoot oneself in the foot.
- V4 Data Types: Request for tagged unions Ralph Lange
- Navigate by Date:
Re: Fundamental Types document Andrew Johnson
RE: Fundamental Types document Jeff Hill
- Navigate by Thread:
V4 Data Types: Request for tagged unions Ralph Lange
RE: V4 Data Types: Request for tagged unions Jeff Hill
ANJ, 02 Feb 2012