Argonne National Laboratory

Experimental Physics and
Industrial Control System

2002  2003  2004  <20052006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  Index 2002  2003  2004  <20052006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020 
<== Date ==> <== Thread ==>

Subject: Re: V4 Data Types: Request for tagged unions
From: Andrew Johnson <anj@aps.anl.gov>
To: Ralph Lange <Ralph.Lange@bessy.de>
Cc: EPICS Core Talk <core-talk@aps.anl.gov>
Date: 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.

References:
V4 Data Types: Request for tagged unions Ralph Lange

Navigate by Date:
Prev: Re: Fundamental Types document Andrew Johnson
Next: RE: Fundamental Types document Jeff Hill
Index: 2002  2003  2004  <20052006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020 
Navigate by Thread:
Prev: V4 Data Types: Request for tagged unions Ralph Lange
Next: RE: V4 Data Types: Request for tagged unions Jeff Hill
Index: 2002  2003  2004  <20052006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020 
ANJ, 02 Feb 2012 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·