Experimental Physics and
Industrial Control System

Benjamin Franksen <[email protected]> · Mon, 15 Sep 2014 16:46:09 +0200

Hi Folks

I am having second thoughts about one of the new features in version 2.2.

tl;dr: I want to go back to allowing calls to the usual built-in pv functions 
only with single channels and instead introduce new, differently named 
functions for arrays of channels ("multi-pv arrays"). My hope is that 2.2 is 
not yet widely used and so the damage this will do is limited.

Here is the long text.

The sequencer in version 2.2, as it stands, aims to allow calls built-in pv 
functions not only for expressions denoting a single channel, but also for 
arrays of channels, wherever this makes sense. Such calls were allowed 
previously, but (with one exception) did not do what you would expect: it 
meant that the function operated on the first element of the array.

The plan for 2.2 was to give a more useful semantics to such calls: do the 
action for *all* contained channels.

I won't go into the details of how to enable/disable this feature with an 
additional option here, because that is irrelevant to the question.

The main gripe I have with the feature is that it blocks the path to a future 
improvement: to allow users to define functions in SNL that can operate on 
channel variables just like the built-in functions. A beautiful side-effect of 
this change (plus the addition of defaults for function parameters) is that 
the built-in functions now have valid SNL types. This means all the code in 
the compiler that handles calls to built-in functions in a special way can be 
scrapped. The compiler initially inserts the appropriate function symbols into 
the top-level scope and all else works as it should... with one exception: 
there is no reasonable systematic way of making a type T and also the type 
T[5] (or *T) instances of the same type scheme. And that means I would have to 
re-introduce all the special handling for built-in functions, which would make 
me very unhappy.

This is why I would like to change version 2.2 so that:

* all existing built-in functions give compile-time errors when called with an
  array of channels

* new functions are introduced in those cases where operating on all contained
  elements of an array makes sense.

Please note that all this concerns only arrays where the elements are 
separately assigned to different channels. It has nothing to do with the 
channel's underlying value type, which can be an array or a scalar.

I have polled for opinions with regard to naming these functions before, but 
my preference has changed to adding the word 'array' somewhere in the name 
(currently I am favoring pvArrayXxx), because when the stuff I am working on 
is finished, there will be more ways to aggregate channel variables: you can 
define structs with members of channel type, for instance, and the functions I 
am proposing to add will only work on simple arrays. (You will be able to 
define you own function for structs that contain channels or even structs of 
arrays of structs etc...)

There is also the one function to consider that had the 'do it for all 
contained channels'-behavior in 2.1 (and even in 2.0): pvPutComplete. It even 
has a number of optional arguments to better support this. My current plan is 
to reduce this function to the simple one-channel variant, and add a new 
pvArrayPutComplete with the extended functionality.

I think all this can be done without introducing any incompatibilities to the 
C API. In fact, I am thinking about fixing those incompatibilities I already 
introduced, namely those concerning the added timeout parameter for seq_pvGet 
and seq_pvPut functions, by adding new C functions seq_pvGetTmo and 
seq_pvPutTmo.

Let me know what you think.

Cheers
Ben

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System