New primitive to get the contained data type of a strictly-typed reference

[raphschru]

What is a strictly-typed reference?

A strictly-typed reference is a kind of reference whose type descriptor contains an inner, user-specified data type.

For example, a queue is a strictly-typed reference because it contains the data type for its elements, specified when creating the queue.

Here is a non-exhaustive list of such reference types:

 - Queue

 - Notifier

 - User event

 - DVR

 - Datalog file reference

 - Strictly-typed control refnum

 - Strictly-typed VI refnum

 - Shared variable

 - Network stream (reader/writer)

 - RT FIFO

 - FPGA IO / register / memory / FIFO / handshake

 - ...

Idea:

Add a new primitive that would output the inner data type of any strictly-typed reference.

Here is a design example of the primitive, which could be named "Get Contained Data Type of Strictly-Typed Reference":

It would work for all the strictly-typed references mentioned above.

Motivations:

The implementation of malleable VIs is sometimes limited (or made complicated) by the fact that we miss some basic "type operators", such as getting the contained data type of a strictly-typed reference. While this missing function could be implemented using some tricks for most strictly-typed reference types, it is for example impossible for user events (See this thread for more details).

Typical application:

A malleable VI that takes a user event (for its type) and outputs a newly created refnum with the same contained data type:

This simple code is currently impossible in the general case due to the nature of user events.

Remarks:

1. The output terminal of this primitive will have to be named exactly as the contained data type, which is crucial for user events.

2. The output would have the LabVIEW default value for the data type (False for booleans, 0 for numerics, "" for strings, ...).

3. The primitive could be placed in a dedicated "Malleable VI Tools" palette.

4. In case the FPGA-specific implementation creates a dependency to the FPGA module, we could have a separate primitive just for FPGA (and also for RT if required).

What do you think?

Regards,

Raphaël.

[Yamaeda]

Sounds like a new Data Type Parsing Variant-VI could solve this. Nice idea.

[raphschru]

@Yamaeda

Yeah but that has to be a primitive (yellow) node, I think there is no way a simple VI or even a VIM could achieve this. 

In the Data Type Parsing palette, there is already "Get Refnum Information.vi" that gives the inner strict type of a refnum as a variant (at runtime). What I want is the inner strict type through data type propagation (so at edit-time).

[avogadro5]

Not opposed to the idea, just pointing out that this one https://forums.ni.com/t5/LabVIEW-Idea-Exchange/Generalize-backwards-propagation-technology-Backwards... might also allow the user event application you're currently unable to do, because you could "backwards propagate" the type from a generate user event node.

[raphschru]

@avogadro5 Even with backwards propagation, we would not reach the complete functionality because the input terminal of "Generate User Event" is always named "event data", so we still miss the data name:

Note the "fake" case structure to avoid sending an actual event to the input user event.

This code would not compile as is due to the unwired "Always Copy" node, so more trickery is needed to get a functional code using backpropagation...

[avogadro5]

Would this trickery do it? Since you have the names you want on the input wire datatype. This is what I use to preserve stuff like cluster names.

[raphschru]

@avogadro5 you have a point for the data name.

There are even multiple techniques to keep the names:

Even with backwards propagation implemented, I would be curious to see how that would work exactly. It would require:

1. A forward propagation to "Generate User Event".

2. A backwards propagation from terminal "event data" of "Generate User Event" to some dummy node like "Variant to Data".

3. A forward propagation from the dummy node to "Create User Event".

I mean, even if backwards propagation is implemented, it would require multi-step forward/backwards propagation, which seems beyond the initial requirement of the idea.