Jump to content
Tomi Maila

Functional Dataflow Programming with LabVIEW

Recommended Posts

When I originally selected the name for my blog ExpressionFlow back many years ago, what I had in mind was functional dataflow programming and the ability to pass any subdiagrams (expressions) around as first class citizens of the language. Functional programming languages (haskell, clojure, lisp) have a lot in common with dataflow world. In principle, calling a function in a functional language is identical to calling a node in a visual language. Passing data between functions happens in an immutable way in functional languages, similar to the concept of data flowing between nodes in a flow-based programming languages. Monads determine execution order of functions with side effects, the same way as flow diagrams determine the execution order of nodes in LabVIEW.

 

Functional programming is often seen as an alternative to object oriented programming. One can solve similar problems of dynamic dispatching either by passing functions around or passing objects with methods around. There are of course multi-paradigm languages supporting both objects and functions like Clojure and Scala. So what would LabVIEW look like if it supported concepts of functional programming paradigm? I posted an article on this on ExpressionFlow and I am intending to study the concept on ExpressionFlow in my future posts. 

 

Would you use functional LabVIEW if such a language existed?

 

My post on how a functional programming could appear in a visual dataflow language:

 

Synchronous Functional Dataflow Programming & Closures of Named Functions

 

post-4014-0-66830000-1386130732_thumb.pn

 

p.s. See Joel's quick intro to functional programming if you are unfamiliar with the concept of functional programming.

 

 

 

 

Share this post


Link to post
Share on other sites

Interesting...The closest I have come to functional programming is with Lua.  I am not even sure it qualifies but have taken advantage of Lua's ability

to assert a 'function string' that can be composed and executed at runtime. BTW, I really enjoyed the Spolsky article and am looking forward to your next post!

Share this post


Link to post
Share on other sites

Reviving an old topic here because I've been playing with F# a bit at work, and it's made me wonder - what if LabVIEW had a type-inference system similar to F# (or ML, or some other functional languages)? Meaning that the compiler can deduce data types at edit/compile time, but it deduces that type only to whatever level of specificity is actually required. For example, in a sort function, so long as there is some way to compare two items of the same type, the actual type doesn't matter. This allows you to write generic functions and still get the benefits of strict typing, and type correctness at compile time. It might be an alternate approach to OOP interfaces for LabVIEW. Of course it would change the look of the language - wires could no longer be colored based on type, since many functions would accept multiple types. I realize it's unlikely to happen in LabVIEW any time soon. Anyone else played with this aspect of functional languages? Comments or thoughts as to whether it could be done in LabVIEW?

Share this post


Link to post
Share on other sites

Reviving an old topic here because I've been playing with F# a bit at work, and it's made me wonder - what if LabVIEW had a type-inference system similar to F# (or ML, or some other functional languages)? Meaning that the compiler can deduce data types at edit/compile time, but it deduces that type only to whatever level of specificity is actually required. For example, in a sort function, so long as there is some way to compare two items of the same type, the actual type doesn't matter. This allows you to write generic functions and still get the benefits of strict typing, and type correctness at compile time. It might be an alternate approach to OOP interfaces for LabVIEW. Of course it would change the look of the language - wires could no longer be colored based on type, since many functions would accept multiple types. I realize it's unlikely to happen in LabVIEW any time soon. Anyone else played with this aspect of functional languages? Comments or thoughts as to whether it could be done in LabVIEW?

 

I hate strict typing. It prevents so much generic code. I like the SQLite method of dynamic typing where there is an "affinity" but you can read and write as anything. I also like PHPs dynamic typing, but that is a bit looser than SQLite and therefore a bit more prone to type cast issues, but still few and far between. That is why sometimes you see things like value+0.0 so as to make sure that the type is stored in the variable as a double, say.

 

Generally, though. I have spent a lot of time writing code to get around strict typing. A lot of my code would be a lot cleaner and generic if it didn't have to be riddled with Var to Data with hard-coded clusters and conversion to every datatype under the sun. You wouldn't need a polymorphic VI for every data-type or a humungous case statement for the same. It's why I choose strings which is the next best thing with variants coming in 3rd.

 

<rant>

I mean. We have a primitive for string to int, one for string to double another for exponential (and again, all the same in reverse). Really? Why can't we connect a string straight to an integer indicator and override the auto-guess type if we need to.

</rant>

 

But yes. I think it can can be done in LabVIEW. They could do it with variants. Not as good as dynamic typing, but it'd be closer. A variant knows what type the data is and you can connect anything to them but they failed to do the other end when you recover the value (I think it was a conscious decision). That is why I call variants "the feature that never was" because they crippled them.

 

I think recovery of data is a bit of a blind spot with NI. Classes suffer the same problem. It's always easy getting stuff into a forma/type/class, but getting it out again is a bugger.

Share this post


Link to post
Share on other sites

I hate strict typing. It prevents so much generic code. I like the SQLite method of dynamic typing where there is an "affinity" but you can read and write as anything. I also like PHPs dynamic typing, but that is a bit looser than SQLite and therefore a bit more prone to type cast issues, but still few and far between. That is why sometimes you see things like value+0.0 so as to make sure that the type is stored in the variable as a double, say.

 

Generally, though. I have spent a lot of time writing code to get around strict typing. A lot of my code would be a lot cleaner and generic if it didn't have to be riddled with Var to Data with hard-coded clusters and conversion to every datatype under the sun. You wouldn't need a polymorphic VI for every data-type or a humungous case statement for the same. It's why I choose strings which is the next best thing with variants coming in 3rd.

 

Forgot about this thread for a month. Shaun, you might have misunderstood how strict typing works in F# (I probably explained it poorly). When you write a function in F#, for the most part you don't specify the actual types of the parameters. Instead, the compiler determines what operations need to be possible on those parameters, and then only allows values to be passed as those parameters when they support the required operations. As a simple example, a sort function might accept an array of an unspecified type, and the only operation that needs to be supported is comparison. The compiler will then let you pass an array of any type that supports comparison to that function. So you get the benefits of both generic functions (because functions don't specify parameter types) and strict type checking (because the compiler can determine at compile time whether the parameters are valid types). That's something I'd love to see in LabVIEW, too.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Similar Content

    • By David Akinpelu
      I am implementing a TCP connection between MyRio(client) and Python(server). The goal is to send data from the server to the client, perform some calculations, and send the result to the server. I need to keep changing the data being sent to the client. I noticed the first data works fine and the result returned to the server, but the client could not read subsequent data. I debugged and was able to detect that the error is coming from the first read function is the "Reading values subvi"  but I don't know how to correct it. How do I go about it?
      I have attached the files below.
      Reading Unknown Bytes from TCP.vi Second_client.vi SimpleServer.py
    • By Deon
      The Threshold Hysteresis VI allows an input (for example, a sensor) to drift out of an inner limit without generating an invalid flag, but if it drifts outside an outer limit it then becomes invalid. For the reverse, when the input crosses back into the outer limit it remains invalid until the value falls inside the inner limit.
      For simplicity, only one input parameter is provided for both the inner & outer limits, and is negated for the lower limit, as generally tolerance limits are equidistant from the nominal.
    • By Deon
      View File Threshold Hysteresis v1.0 LV8.6.1
      The Threshold Hysteresis VI allows an input (for example, a sensor) to drift out of an inner limit without generating an invalid flag, but if it drifts outside an outer limit it then becomes invalid. For the reverse, when the input crosses back into the outer limit it remains invalid until the value falls inside the inner limit.
      For simplicity, only one input parameter is provided for both the inner & outer limits, and is negated for the lower limit, as generally tolerance limits are equidistant from the nominal.
      Submitter Deon Submitted 11/10/2014 Category General LabVIEW Version License Type  
    • By jossie
      Hello I am quite new to labview and I have some questions regarding labview. We have came up with a simulation build in labview as shown in the folder. However, we will be making use of Myrio to connect current and voltage sensors to send the data to labview when labview is running. We are currently having difficulties trying to search if it is possible to send the wave files and the popout messages ( messagebox.vi and Player2Wins.vi) to NI Dashboard for Labview in Ipad by using myrio. Is it possible for myrio to store wave files and the additional VIs and sending these to NI Dashboard for Labview? 
       
      Otherwise, it is possible for Labview to send the entire program.vi, messagebox.vi and Player2Wins.vi to cloud and people are able to see the GUI in program.vi remotely? ( We have found information like Labview web services etc. We hope that people are able to view our GUI and press the " Press start" button as well as closing the popout messages in a website not from our local network). 
       
      I sincerely apologize if what I am asking does not make sense to people who are reading this. I hope that someone will help me with this as it is very difficult for me to do and I need some guidance from people who are familiar with these. Thanks for taking your time to read and your reply. 
      Simulation_Build_(3).zip Pop-up_Message.vi Player2Wins.vi
    • By edupezz
      Hello, i created a new tips repository in:
      https://edupez.com/
      English and Portuguese
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.