Experimental Physics and Industrial Control System
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
- Replies:
- Re: V4 Data Types: Request for tagged unions Benjamin Franksen
- References:
- RE: V4 Data Types: Request for tagged unions Jeff Hill
- Navigate by Date:
- Prev:
RE: V4 Database Access Jeff Hill
- Next:
Re: Fundamental Types document Benjamin Franksen
- Index:
2002
2003
2004
<2005>
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
RE: V4 Data Types: Request for tagged unions Jeff Hill
- Next:
Re: V4 Data Types: Request for tagged unions Benjamin Franksen
- Index:
2002
2003
2004
<2005>
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024