Experimental Physics and
Industrial Control System

Benjamin Franksen <[email protected]> · Thu, 16 Jun 2005 12:55:26 +0200

On Wednesday 15 June 2005 23:12, Andrew Johnson wrote:
> 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.

We should be wary of premature optimization. Whether we provide a 
specialized version of the tagged union meta-data interface for the 
case where all additional data is empty should not influence the design 
decision at this stage. I think it is enough to note that such an 
optimization is easily possible.

BTW, I don't think it is so much more complex: The daEnum interface is 
clearly already introspective. How this introspection is extended to 
cover additional data per tag value depends on the not-yet-decided 
question of how the DA interface should look like, that allows to query 
what data (properties, types) are available, without querying the data 
themselves. This will then simply plugged as an additional argument to 
the daEnum query for the enumeration strings.

> 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?).  

It must disconnect, indicating that the value in question no longer 
exists. Note that a similar question must be answered for the case of 
adding/removing views. Here, too, the client will need to receive 
notification that a certain value is no longer available. We could make 
this a dedicated event type so that clients can react in a generic way 
to such conditions.

> If 
> these are the inputs to the state machine, where do you put inputs
> that are needed by more than one state?

Ralph's example was a bit unfortunate in that it mentions a not yet 
completely worked-out proposal for a new version of SNL. I'll cover 
these in a separate document.

Meanwhile let me give two other examples. The first one is analog 
conversion: Linear conversion needs additional parameters like EGUL, 
EGUF, etc.., that are only valid and only needed if the conversion is 
specified to be LINEAR. Thus, a tagged union would be most natural, 
i.e. instead of

menu(menuConvert) {
    choice(menuConvertRaw, "Raw")
    choice(menuConvertLinear, "Linear")
    choice(menuConvertTable, "Table")
}

we would have

union(analogConvert) {
    choice(unionConvertRaw, "Raw") {}
    choice(unionConvertLinear, "Linear") {
        field(linearConvert, struct(linearConvert)) {
            special(yes)
        }
        # or otherwise move all the fields
        # from struct(linearConvert) here; matter of taste.
    choice(unionConvertTable, "Table") {
        field(tableName, string)
    }
}

Second example is the SCAN field. It would be quite natural to have

union(unionScan) {
    choice(unionScanPassive, "Passive") {}
    choice(unionScanEvent, "Event") {
        field(eventSpec, however_we_represent_named_events)
    }
    choice(unionScanInterrupt, "Interrupt") {}
    choice(unionScanPeriodic, "Periodic") {
        field(scanRate, float32)
    }
}

> 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.

and

On Thursday 16 June 2005 01:46, Jeff Hill wrote:
> I think that unions are really best summarized as a way to save space
> by storing different things in the same place at different times. 

Yes, in C unions are used to save space.

But the idea for *tagged* unions is not to save space. The idea is to 
make data available or not depending on the state of the tag. It is a 
*consequence* of this semantic property, that memory can be safely 
shared between data of separate tag values, not the other way around. 
However, the question of whether the memory space is shared or not is a 
low-level implementation issue and not relevant to the data type as 
viewed from the outside, i.e. from either DBD or DA.

> Of 
> course there are chances for mistakes because the type varies at
> runtime instead of being checked by the compiler. So, looking at this
> example I would probably advocate storing the date for different
> states independently unless there is a significant storage space
> optimization that might be obtained.

Repeat: this is an implementation question. We should first be concerned 
about the high-level semantics. On this level, since we will use DA to 
access the database, there can't be any static type checking at the 
access level. However, we have dynamic type checking (and conversion, 
if appropriate) at run time.

Ben

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System