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 Attachment:
signature.asc
Description: This is a digitally signed message part.
- Replies:
- Re: Sequencer 2.2.0 J. Lewis Muir
- RE: Sequencer 2.2.0 Mooney, Tim M.
- Re: Sequencer 2.2.0 Benjamin Franksen
- References:
- Sequencer 2.2.0 Benjamin Franksen
- Navigate by Date:
- Prev:
RE: Does the record type lsi support a long string longer than 40 bytes? Mooney, Tim M.
- Next:
RE: Does the record type lsi support a long string longer than 40 bytes? Yun Sangwon
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
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:
Sequencer 2.2.0.2 Benjamin Franksen
- Next:
Re: Sequencer 2.2.0 J. Lewis Muir
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
<2014>
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|