Implicit element to array conversion

[JimChretz]

Is it possible to have something like this? Even with 2D, 3D,... arrays.

[altenbach]

Why would you want to connect a scalar to an array?

Where would that be useful? I don't see it.

[Intaris]

No. The feedback that the number of dimensions dont match is an important debugging help. I vote no.

[JB]

No for the same reason as Intaris.

[AristosQueue (NI)]

In my opinion, that would likely be a feature more likely to hurt users than to help users. It is a trade off of programmer speed-of-development vs confirmation of programmer intent. Strong type systems in LabVIEW are a big part, in my opinion, of what gives us confidence to use the language for industrial control and test verification: the programmer provides details of what is intended at each stage and the compiler confirms that this intent is sane. Contrast that with weak type systems where the compiler guesses what the programmer intent was. I'm supportive of conversions that are near synonyms (like error cluster to Boolean), but anything where the semantic meaning of the wire is contorted crosses a threshold for me. Coercion from scalar to array is the exact kind of weak typing that I do not want infecting LabVIEW.

https://en.wikipedia.org/wiki/Strong_and_weak_typing

I'm going to stress: this is my personal opinion. As a member of R&D, I have not formally evaluated whether LV users would be more benefited from the greater flexibility in programming (witness the value that weak typing has in JavaScript) or from the greater confirmation of programmer intent (the value of the strong typing today).

[RavensFan]

If this idea was implemented, just change the wire color to thick blue.  Then call it the "Dynamic Data Type".

Seriously, implementing this idea leads to the same problems the blue DDT wire causes in that when you connect it to an item that really isn't comparable to the underlying data on the wire, users can't figure out why their code isn't working the way they think it should.

[AristosQueue (NI)]

RavensFan mentions the dynamic data type. That's a perfect example of the on-going tension between weak and strong types. I have heard positive things said about the DDT for people trying to wire diagrams, but I also hear customers claiming LV was broken when actually it was just the DDT being overly helpful with coercions and the programmer losing track of the type in their head. I do not know whether the gain or the pain was greater -- I  suspect the pain. The DDT aggregated many types together. Would it have been more successful if it had aggregated only two (double and array of double)?

[JimChretz]

I don't follow you guys, why are you talking about dynamic data type and weak type?

The result is pretty obvious to me, you have an array of size 1, downstream the array can be extended or emptied... Obviously the typedef of the array must be the same of the element. Perhaps the issue in my "art-painting" the red coercion dot is the same as numeric coercion dot, it should be a different color/style for the array coercion. Perhaps bright green is better?

It can be useful when you have a case structure with an array output, in some cases you have multiple elements but in some cases just one element to pass, it would be nice to get rid of the build array and have some obvious indication that it's coerced to an array.

My question is just why not? And none of you convinced me it could cause issues.

[altenbach]

If you are trying to wire a scalar to an array indicator, it means you have the wrong indicator type. Why is it an array indicator in the first place then?? Wouldn't it be easier to change the indicator? 

(The discussion of dynamic data came up because it allows dynamic data containing millions of data points to be wired to a scalar indicator without a broken wire. While this is the reverse of what you are trying to do, most programmers still don't like it because it sweeps a lot of potentially important stuff under the rug while telling you that everything is fine).

But yes, I agree that sometimes LabVIEW (with default settings) tries to "fix" things behind the scenes, avoiding broken wires at the cost of potentially completely wrong code. (Autoinsert feedback node is one such monstrosity! :D) In the same spirit, your idea has some validity and your array indicator could show the value of the single array element unless somebody messed with the index terminals, at which point you would not see anything useful at all.

Your example with the array indicator is just the tip of the iceberg salad, though. Would you also want a "scalar to array coercion" if you wire a scalar to an array function from the array or linear algebra palettes, etc.? In many cases a reasonable default behavior could be defined (coerce to a single element array with the lowest allowed array dimensionality, e.g. 1D for the upper input of "index array" and 2D for "transpose array"). Would you want to allow wiring of a scalar to a waveform graph?

Personally, I think the current behavior is just fine.

[AristosQueue (NI)]

jimmy.chretien wrote:

> Perhaps bright green is better?

The problem is not with the style of the coercion dot. The problem is with LV allowing the coercion to happen at all.

A completely weakly typed language would allow you to wire any wire to any terminal and not get a broken wire. The compiled program would do the best coercion it could do and otherwise throw a runtime error. There are real-world programming languages that work like this.

A completely strongly typed language would disallow wiring an Int32 to a UInt32. The programmer would need to drop a coercion bullet explicitly. In these languages, the compiler does not make any assumptions about what the user intended -- if the types do not match, the compiler throws an error -- in LV, that equates to breaking the wire.

LabVIEW, like most languages, takes a middle path of allowing some coercions but not others. It requires striking a balance between guessing whether the user meant to do that or whether they wired on accident or with a lack of understanding about what was going on. In general, you find weakly typed languages near prototype code, code that needs to change frequently, and code that deals with data coming from unknown sources -- thus those languages are favored in web development. Strongly typed languages dominate the more mission critical applications because the compiler serves more and more as a double-check on the programmer to make sure they are issuing exactly the right instructions to the computer.

The DDT was an attempt by LabVIEW to have our cake and eat it too. We remained a strongly typed language generally but we introduced a bunch of functions that output this very generic wire capable of carrying anything, in order to make learning LabVIEW easier. In the years since, I've been told (by faculty members that I talk to at universities) that new research shows new programmers do bettter in strongly typed languages because everything is there on the screen and they aren't guessing about what is wrong. Sorry, I don't have sources to cite for you on that research, just passing along annecdotes.

After the many languages I have worked in over the decades, I am a strong believer in strong type safety. I take the position that LabVIEW is not quite strong enough for most of us. There are classes of errors that I see regularly because LabVIEW only has a "string" type, when actually we could benefit from "UI string" and "GPIB string" and "flattened data string" being completely different types that require an explicit coercion bullet to convert -- and those would not be the only types of strings. Similarly, I wish we could strengthen the units feature on numerics... right now, units are largely unusable because the feature is incomplete -- too many functions just strip the units off instead of handling them. I'd allow coercion dots between numerics of the same quantity (i.e. inches to centimeters) but you'd have to have an explicit coercion to wire a raw double to an input that took centimeters. I am fully aware of the difficulties and downsides this would introduce into the language and the open riot that would take place if those rules were applied to certain APIs, but it remains my theoretical position that after the yelling died down about a year later, the quality of LV code across the board would improve.

In addition to what Altenbach wrote, DDT also allows a scalar to wire to an array. Basically, DDT does exactly what the idea is asking for -- it abstracts away whether or not you're working with a scalar or an array, so the diagram just accepts whichever.

[JimChretz]

What else than an array with one element could you expect from that coercion?