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: EPICS base V4: iocCore database
From: Marty Kraimer <mrk@aps.anl.gov>
To: Benjamin Franksen <benjamin.franksen@bessy.de>, Andrew Johnson <anj@aps.anl.gov>
Date: Mon, 21 Feb 2005 10:56:32 -0600


Benjamin Franksen wrote:

On Friday 18 February 2005 18:12, you wrote:
I have again updated dbd.html which is available via

http://www.aps.anl.gov/asd/people/mrk/epics/base/V4

Hi Marty,

one comment regarding the epicsTypes document and a proposal for an additional structured data type.

First, I don't understand why every library is specified as as a structure of function pointers ("interface"). IMO, this only makes sense if you anticipate the interface to be passed as an argument, because there might be different implementations of the same interface. If all you ever use is one and the same global pXYZInterface, then all this gives you is the run-time overhead caused by the additional level of indirection.

One reason is that the epicsShare nightmare almost goes away. Instead of

epicsShareFunc <type> epicsShareAPI xxxFunc(...

for every function in a library . By using an interface there is just one definition such as

epicsShareExtern asynManager *pasynManager;

Another reason is "Everything is an interface" seems like a good idea.

Note that most interfaces will have multiple implementations just like for asynDriver.

A comment about using C++ instead of C. This could all be done in C++ using pure abstract classes. But when I think about the syntax, the C++ version looks worse (at least to me) than the C version with one exception.

C forces the definition

typedef struct <someInterface> {
   <type> (*method)(<args>);
  ...

Rather than

struct <someInterface> {
   <type> method(<args>);
  ...

Other than that the C++ syntax is more verbose than C.

Second point. As a more general observation, much of what I read in the above documents reminds me of inventing yet another (domain specific) programming language. Only that it is not for programming, but restricted to data specification (no way to define functions or routines). The latter is expected to be done in a separate language (C, sometimes SNL). Although the data model is strongly influenced by what is available in C, it is still hard to come up with good generic routines to handle this data in C. This is no wonder, given that C is not very powerful when it comes to genericity.

But I digress. What I want to point out is that there is one very useful thing missing from the data model, namely algebraic data types, a.k.a. tagged unions. A syntax could look like this

union(name) {
	choice(choice_name,"choice_value",choice_data)
}

where 'choice_data' can be any valid data type, including struct or another union. Thus, menu would be the special case where the 'choice_data' is void (or null; another basic data type to be added).

Let me give an example where I missed the possibility to define such a data type: When lately I wrote a general conversion record, I would have liked to define something similar to the following:

union(convSpec) {
   choice(convLinear,"Linear",linearConvSpec)
   choice(conv1DTable,"1D Table",tableConvSpec)
   choice(conv2DTable,"2D Table",tableConvSpec)
   choice(convSubroutine,"Subroutine",subroutineConvSpec)
}

struct(linearConvSpec) {
   field(offset,DBF_DOUBLE)
   field(slope,DBF_DOUBLE)
}

struct(tableConvSpec) {
   field(name,DBF_STRING)
   field(directory,DBF_STRING)
}

struct(subroutineConvSpec) {
   field(name,DBF_STRING)
}

Even with your extended V4 dbd language I could not do this, but had to split the conversion specification to many fields. This raises many problems, for instance: since there is no atomic update(*) of the whole conversion spec, when is the update complete and to be acted upon? No way to know, other than introduce yet another field as a trigger. Record support code becomes unnecessarily complicated. Furthermore, each specification field must be duplicated, in order to save the current values while new values are in the process of being set. Etc. etc.

Andrew also suggested a union.

JAVA does not have a union. Will this cause us any problems?

Marty

Cheers,
Ben

(*) I understand that EPICS V4 will provide some method to atomically update structured record fields.





Replies:
Re: EPICS base V4: iocCore database Benjamin Franksen
Re: EPICS base V4: iocCore database Benjamin Franksen
References:
Re: EPICS base V4: iocCore database Marty Kraimer

Navigate by Date:
Prev: Re: EPICS base V4: iocCore database Marty Kraimer
Next: Re: EPICS base V4: iocCore database Benjamin Franksen
Index: 2002  2003  2004  <20052006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020 
Navigate by Thread:
Prev: Re: EPICS base V4: iocCore database Marty Kraimer
Next: Re: EPICS base V4: iocCore database Benjamin Franksen
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 ·