> I don't know why you have those "10"s wired or the orange wire coming out of the structure
When I first imagined it I imagined being able to call the anonymous VI while also defining it. Reading your comments on closure and seeing the changes, your revised image makes more sense to me than my original submission. I like that much better.
> What do we do for a panel if you do wire that "define connector pane" input? Well, LV can autogenerate one -- default control for each type.
Do you mean *don't? I'd think it would be nicer for LV to auto-generate the connector pane. I'd think something that looks more like the call library node would be cleaner. A node that populates its ins/outs based on the ins/out to the anonymous VI, determined based on the connections of the structure. Even still, having a connector pane and calling by reference makes more sense in LV land, even if LV auto-generates the connector pane for you.
> You want some really fun brainstorms? Draw a channel wire crossing that Anonymous VI structure boundary and ask yourself if that's meaningful. Hint: it isn't meaningful as channels are defined today, but the places it'll lead you in terms of async communication models and models we might use for them are intriguing.
You make my brain hurt. I imagine each callback to the anonymous VI would have some interaction with the same channel. For instance, I could push something into a channel just by calling back to the anonymous VI. If the anonymous VI structure is in a loop, I'd think we'd have several anonymous VIs all sharing the same channel. Who knows, maybe I just completely missed the mark ;P.
I'd definitely think the ability to implement closures in LV would be super cool! I'd also shamelessly use it to reduce redundant code when I don't want to create a SubVI.
@AristosQueue, I definitely missed that part. Having the anonymous function in a separate BD makes more sense. In a way, they will be the Python lambdas equivalent.
The reference to JS is the fact that anonymous calls are heavily used for callbacks and the intention was more like a summer "joke" (we finally have warmer weather in Norway)
As a comparison (correct me if I'm wrong), this would provide similar functionality as a c++ Lambda function.
It's quite hard for me to so see the potential, but I think at least in some corners of programming it would radically change the way we (have to) do thinks.
> As a comparison (correct me if I'm wrong), this would provide
> similar functionality as a c++ Lambda function.
Similar bordering on identical, depending on implementation details.
> It's quite hard for me to so see the potential, but I think at least in some
> corners of programming it would radically change the way we (have to)
> do thinks.
See LV 2018 shipping example
"examples\Malleable VIs\Nested Malleable VIs\Malleable VIs - Nested Malleable VIs.lvproj"
Consider how much easier it would be to write local sort specifications if you had a structure like this.
See LV 2017 or 2017 shipping example:
"examples\Channels\Replacing The Function At The Heart Of An Algorithm At Run Time\Replacing The Function At The Heart Of An Algorithm At Run Time.lvproj"
Consider the improvements to ease of programming if we had a feature more directly addressing the need than the 4 (3 in 2017, 4 in 2018) discussed in the example.
PS: I wish all users at CLD level or higher would look at that second example, just as a matter of course. It is listed as a channel example, but it goes waaaaay beyond that and attempts to provide a fairly in-depth education on framework design. I wrote that example to try to improve the LV general knowledge around such systems.
Good examples. I think over use will be one of the risks. Often DD might be more appropriate.
This would require the RTE to get compile capabilities, right? Or those 'external' values need some kind of value stub in pre compiled code, allowing the RTE to replace then when evaluating the anonymous method. That might be tricky...
> This would require the RTE to get compile capabilities, right?
Nope. 🙂 Let's take the example of an integer. The original code inside the structure is compiled to create an anonymous VI with a "0" somewhere in it is code. When the containing VI executes, that structure running will copy the anonymous VI [essentially the same tech that allows a .vit to be cloned at run time] and replace the "0" in the code segment with whatever value is coming into the tunnel. No compiler is needed because it's a value replacement and the code instructions are identical.
> That might be tricky...
Of all the issues involved with this structure, that's on the easy list. 🙂
Thanks, that's what I tried to say with "those 'external' values need some kind of value stub in pre compiled code, allowing the RTE to replace then when evaluating the anonymous method. ".
RTE compilation would have some use cases, but in this one it will be terribly slow.
Funny how this is almost the exact reverse of a .vim. A .vim is a VI that is compiled into the diagram, and here we want a VI to be created from a piece of diagram, without making a VI. Could be just me...
It's not just you. VIMs and anonymous VIs are two sides of one coin -- one flexing on data type, the other on data. And that run time compiler you speak of? There's some major languages, for example, C#, based around just-in-time compilation.
The source code works with conceptual data types.
The compiled code works with specific numbers of bytes.
Flexibility on both is highly desirable for maximum code reuse.
And there's an endless desire to bring both of them together in one syntax. It continues to be an area of interest to me.
