Experimental Physics and
Industrial Control System

Andrew Johnson <[email protected]> · Wed, 15 Jun 2005 16:12:59 -0500

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;
                   int j2;

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

Address?))

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.

- Andrew
--
Podiabombastic: The tendency to shoot oneself in the foot.

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System