Allow "Add Array Elements", "Multiply Array Elements", "And Array Elements" and "Or Array Elements" to work on clusters too

[fabric]

This is really just a small time-and-space-saver...

It would be nice if the * Array Elements functions found in the Numeric and Boolean palettes would work directly on clusters:

Yes, the names would probably need to be changed ... but on the positive side, these functions do not even reside in the Array palette!! (Maybe they were destined for better polymorphism from the start )

It would be an added bonus if Darin's complementary idea was implemented at the same time.

[Dragis]

What I take away from this is that you'd like LabVIEW to essentially allow the explicit coercion between a cluster of similar types to an array to happen implicitly. If that were the case, you'd see a red coercion dot whenever you wire a cluster to an array terminal of similar type.

[fabric]

Actually, I imagined it more like the existing magic that takes place when you wire a cluster into the "Add" primitive (or most of the numeric operations), i.e. that they would be inherently polymorphic:

If the cluster contains mixed types then I'd expect a coersion dot, but if the cluster is "pure" (e.g. all doubles) then no coersion dot would be necessary, right?

Also, I don't necessarily think of this as an "implicit coersion to array"... Surely the compiler doesn't need to allocate any memory to process the elements of a cluster, other than for the actual result?

[Dragis]

I see what you are saying, and I'm intrigued by the idea, but I'm having a hard time correlating this to existing language semantics. For the non-array primitives (e.g. add, subtract, ...) the definition is well defined to "perform the operation element-wise on the inputs" and then if you are aggregating perform the aggregation on the results. In this case, it is not element-wise to start with so I'm not sure how to change the semantics to fit this scenario well. Especially when you start talking about wiring in arrays of clusters and clusters of arrays ...

[fabric]

As far as semantics go: Yes, the proposed behaviour would differ from the way non-array primitives work with arrays... but I don't see this as a limitation.

If the targetted primitives simply had a name change to "Add Elements" (rather than "Add Array Elements"), etc. then from a usability perspective the behaviour would be obvious. In fact, if arrays of clusters and clusters of arrays were also cleanly supported then I could see this as an extremely useful extension to the language!

In terms of implementation, I'd love to see a native traversal of clusters to avoid any intermediate conversion to array, but if I couldn't get speed *and* convenience then I'd settle for convenience! 

[Darren]

Any idea that has received less than 5 kudos within 5 years after posting will be automatically declined.