For Each Element in Map

[thadyale]

I frequently perform operations on Maps of Objects which hold private data where I do not intend to alter the structure of the Map.

Existing Solution

However, Maps are a bit clunky to work with when operating on all Elements. You must first get the list of all Keys, then use an In Place Element Structure within a For Loop and Shift Registers to operate on each Element as follows:

Potential issues with this:

1. Unnecessary branch of the Map which may not be optimized by the compiler
2. Excessive block diagram editing which slows down the development time involved when working with Maps
3. Potential for syntactical errors due to complexity of this operation

Proposed Solution

It would be great if there were some kind of auto-associating tunnel available to For Loops:

Note that the Key is not modifiable, nor is it even available within the For Loop.

Perhaps the tunnel icons must be changed so they are not confused with shift registers.  I just copied the association icon from the map datatype icons.

This level of functionality is similar to the syntactical abbreviations available in most languages which support maps as a standard data type.  I originally wanted this kind of functionality for Sets as well, however modifying the values may result in structural changes to the set itself due to the uniqueness constraint.  As such, this is only applicable to Map Values within For Loops.

It may not be obvious, but this kind of tunnel would not be available to While loops.

Selection

This option would be available on the block diagram through the context menu items of the Map datatype Input Tunnel to the For Loop.

[AristosQueue (NI)]

Duplicate (mostly): https://forums.ni.com/t5/LabVIEW-Idea-Exchange/New-tunnel-mode-Build-set/idi-p/4169443

(Duplicate because if we do one we'll do the other.)

[AristosQueue (NI)]

Note that there's no need for a new input tunnel mode. With today's arrays, if you autoindex on one side and reindex on the other, LabVIEW is smart about consolidating the memory -- it looks upstream, and if the array is not forked elsewhere, the operation is automatically in place. The same compiler smarts would apply to a set or map indexed on one side and built on the other, assuming we detect that the key value is not modified.

(In case you can't tell, yes, this has been kicked around by R&D. It's a big enough project that it hasn't been able to get priority, but it is something we'd like to do, if we ever get time.)

[thadyale]

It's mostly the syntactical improvement that I am looking for - not the compilation benefits.  As of right now, the approach requires too much effort.

1. Create for loop
2. Tunnel map
3. Create unbundle by name, select Key
4. Autoindex output of Keys
5. Create for second loop
6. Tunnel map into for loop
7. Create in place element structure within for loop
8. Add Map Get / Replace Value on In Place Element Structure
9. Convert map tunnel into shift register
10. Wire in both input and output shift registers to In Place Element Structure
11. Wire Keys through for loop into In Place Element Structure

Only THEN can you perform your basic logic.  This is a minimum of 30 mouse clicks when you consider the interaction with the block diagram menu pallet and an intangible cost of developer brain power to think through the process of implementing the code.

Compare this to c++ https://en.cppreference.com/w/cpp/algorithm/for_each

[thadyale]

I whole heartedly support the auto create set tunnel.  I disagree that these two are related.  I actually drew up this idea in regards to sets at first, but their element uniqueness and auto-sorting change the structure of the resulting set while this preserves the structure of the map.  That makes these two concepts fundamentally different both in implementation and also resulting use cases.

[AristosQueue (NI)]

Hm... good points. I withdraw my comment about duplication.

[wiebe@CARYA]

If there was a way to auto index the output to a map, wouldn't that solve the same issue:

IIRC, that has been suggested, but can't find it atm.

As I read this idea, it seems it requires a new "map value" (probably "set value" as well) data type.

Having an "auto index to map\set" output would also be useful for building maps\sets in loops without having a map\set as input.

[pauldavey]

The proposed syntax (as drawn) does not give you access to the key of the map. As such, there would be situations when it does not give any advantage.  Of course, it could not work with both the key and value because if you changed the key, how would it behave?

In other languages, when you use foreach, it seems many (eg Java, C#) only provide read-only access. So the loop would be operating on a copy of each value any way. I think the IPE is unavoidable.

[wiebe@CARYA]

>In other languages, when you use foreach, it seems many (eg Java, C#) only provide read-only access. 

From std::for_each - cppreference.com:

    std::for_each(nums.begin(), nums.end(), [](int &n){ n++; });

Seems to be writing...

[wiebe@CARYA]

>As I read this idea, it seems it requires a new "map value" (probably "set value" as well) data type.

This isn't true (feel free to tell me). I was mislead by the class wire, making the example a bit more complicated.

This could be more like a shift register (in stead of a tunnel) because

1) they are paired (tunnels aren't).

2) this wouldn't require altering with the tunneling.

For sets this would be weird (as the input and output elements don't correlate) but it would also work well for arrays (although it wouldn't add much over normal tunnels).