Re: Sequencer 2.2.0

[Benjamin Franksen <benjamin.franksen@helmholtz-berlin.de>]

Hi Everyone

thanks for the quick responses so far.

I forgot to mention one ugly little detail:

The pvArrayXxx functions will not get the array size as a default 
argument as was the case with e.g. pvPutComplete() before. For instance, 
with

  int a[2];
  assign a to {};

you you'll have to say

  pvArrayPutComplete(a,2);

if you want to check whether all elements have completed their last 
asynchronous pvPut.

[The reason is, of course, that arrays are not first-class citizens in 
C: when you pass them to a function the size information is lost. I 
could make them first-class in SNL but only at the cost of completely 
breaking compatibility with existing code.]

Cheers
Ben

On Monday 15 September 2014 16:46:09 Benjamin Franksen wrote:
> 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

-- 
"Make it so they have to reboot after every typo." ― Scott Adams

Attachment: signature.asc
Description: This is a digitally signed message part.