Malleable control labels

[wiebe@CARYA]

I'd like to get an Malleable VI's input wire label from within the .vim.

It's convenient to use a wire's label in a sub VI, for instance to get a value from a file:

If the input is a variant, I can get this label from it. However, I like to return the same type that I wire to the input... A .vim can be used to make the output the same type as the input. However a .vim will fail with the label part:

The type info's label will always be "Numeric". The type adapts to the wire, but the label does not.

It would be really useful to me if the label of the .vim's input would change with the type, to the label of the wire that's wired to it. I'd think other would find this useful as well.

[AristosQueue (NI)]

> Wire a cluster: the string input is ignored.

The string input would not be ignored. The string would be the name of the cluster overall.

[drjdpowell]

> Checking with the dev team, this was a very conscious decision.

That was a terrible decision.  Is there any hope of reversing it?

[drjdpowell]

BTW, they also seem to have eliminated "unbundle" (not by name).  It's not possible in NXG 2.1 to use clusters as a "tuple", an ordered set of unnamed elements. Instead one has to manually order the autogenerated "element x" names.  A lesser use case perhaps, but cluster elements named "element 1" are a clunky worst-case mix of properly named or unnamed-and-ordered collections of data.

[drjdpowell]

Speaking about NXG, still, is it possible to have the compiler "backtrack" along a wire to get the label of the output terminal it originates on?  This would not be needed in general, but only for certain inputs:

1) the "create cluster" primitive, so it can generate a meaningfully-named cluster.

2) a new primitive, that outputs a string containing that label.  This would compile into a string constant and so would be much higher performance for use cases like Wiebe shows.  This is similar to AQ's proposed special subVI terminals, but I think it makes more sense to be a standard-looking primitive.

3) give control input terminals a new setting "adapt to label", analogous to "adapt to type".  Then for all inlined subVIs (including VIMs) have the compiler backtrack out into the Caller to get the label of the wire source.  This implements Weibe's idea.  Side note: you could consider extending this for outputs to.

Together, this would allow the same kind of 3rd-party advanced tools (written in G, not C++/.NET, thank you) that we currently do with Variants in Current LabVIEW, but compiled in and without the current Variant-dynamic overhead.   A big improvement.  I could get excited about NXG for that.

[Taylor_R.]

We have indeed made the conscious decisions to a) eliminate the nameless unbundle and b) not propagate names as metadata on the wires in NXG. First off, thanks for the feedback on these decisions, as we always want you all's feedback, good and bad.

Both of these decisions were made with the principals of requiring more strict and explicit naming of entities in an effort to make the language safer and more straightforward for "average" users. However, we, and specifically me and my Advanced Language teams, are very interested in the workflows that you all are discussing. We want to provide solutions to these workflows, and to do that I will be studying these requests in more detail as we plan out our future implementation plans for NXG. These are exactly the type of workflows that my teams were chartered to fulfill. We may give you solutions that are different than in the current LabVIEW product, but we are striving to provide useful and efficient solutions as NXG progresses.

Thanks,

Taylor

[drjdpowell]

I appreciate the desire to make the language safer and more straightforward, but I'm not sure the NXG clusters are successful at that, as the compiler still ignores names at subVI terminals, instead matching on order of elements.  New Users still need to learn that the names really don't matter, order is primary.  

Also, I doubt to usefulness of names like "element 3", "numeric constant" or "numeric constant_2".  

[AristosQueue (NI)]

> Also, I doubt to usefulness of names like "element 3", "numeric constant"

> or "numeric constant_2". 

One argument for the utility of these generic names is that it makes it possible to search for all the places where the programmer has not explicitly provided names. Today, names are just picked up from the ambient environment somewhat randomly. Having default names means we could ask LV to search for "things that have their default name" and get meaningful results.

I don't know how strong/weak that argument will be in practice, but it appealed to me as potentially more helpful than today's behavior.

[wiebe@CARYA]

>> Wire a cluster: the string input is ignored.

>The string input would not be ignored. The string would be the name of the cluster overall.

In my use case (where constant labels are used), the constant labels of the cluster elements are used. So when a cluster is wired, the string input is not useful since element labels are used. With constants, the string input is required.

[drjdpowell]

>Having default names means we could ask LV to search for "things that have their default name" and get meaningful results.

In that case I would suggest you use "numeric constant_B" rather than "numeric constant_2", as the latter may be interpreted as the second element of the cluster, or the second numeric constant, neither of which it necessarily is.

[drjdpowell]

>The string input would not be ignored. The string would be the name of the cluster overall.

AQ, Wiebe is making an INI library, where it is natural to work in name:value pairs and use clusters as sets of name:value pairs.   In JSONtext, it was more natural to associate clusters with JSON Objects, at not work in bare name:value pairs, so I didn't actually need this idea for that.  But I am familiar with lots of name-value uses, where the lack of wire names matters