Can a typical LV application be constructed along functional paradigms?

[AlexA]

Hi guys,

 

I've just started to play around with Haskell and learn about functional programming paradigms and I was wondering, as per title:

 

Can a typical LV application be constructed along functional paradigms?

 

Hypothetical application:

2 Analog Inputs and 2 Analog outputs connected to some process, some sort of controller, a UI for interacting with the controller, and file IO.

I typically don't see functional paradigms applied to hardware control. I don't know if this is just something that people have avoided doing or whether there just hasn't been any interest. In any case, I'm trying to imagine first of all what LV native mechanisms could be uses to construct a "functional" type application, and secondly, whether there would be any advantages in doing so? Particularly in ability to reason about behaviour.

 

Hope this sparks some interesting discussion.

Kind regards,

Alex

[Yair]

There was some discussion on this a while back on Tomi's blog, which seems offline at the moment - http://lavag.org/topic/17804-functional-dataflow-programming-with-labview/

 

You could try pulling a cached copy from Google or the Wayback Machine.

 

 

That said, I don't think the discussion got very far on a technical LV level. My own understanding of functional languages is very superficial, but as I understand it, this is something that needs to be deeply engrained in the language itself. I'm assuming you could put together a crude implementation which would implement some of the basics of functional programming by calling VIs by ref and passing in arguments as key-value pairs, but I doubt it would be elegant or perform well.

 

It reminds me of (I think, can't be bothered to look it up) an XKCD comic which had a caption along the lines of "functional programming combines the power and elegance of abstract maths with the ease of understanding of abstract maths".

[jcarmody]

http://www.xkcd.com/1270/

 

[infinitenothing]

Here's another attempt:

https://decibel.ni.com/content/docs/DOC-39565

 

It's something I think many developers want to do but it's going to need some more infrastructure to make it efficient to run and easy to use.

Edited December 23, 2014 by infinitenothing

[ned]

LabVIEW is often used for hardware control and user interfaces. Both involve side effects - things that happen that aren't part of a computation and often must occur at a particular time or in a particular sequence. Functional languages deliberately don't deal well with side effects. While there are ways around this, it might become tedious.

 

LabVIEW also allows functions (VIs) to return multiple values - something I haven't seen in any other language, and which I think would limit the options for higher-order functions. The lack of tail recursion in LabVIEW is also an issue.

 

That said, there are some ways in which LabVIEW resembles a functional language, particularly the immutability of values on wires. I'd love to see a type inference system, similar to the one in many functional languages, make its way into LabVIEW, since that would make it much easier to write polymorphic VIs. I tried to explain this in the thread Yair mentioned.

[Testy]

Functional languages deliberately don't deal well with side effects. While there are ways around this, it might become tedious.

 

I disagree with this. Composing IO monads with Haskell's do-notation looks almost exactly like effectful imperative programming.

 

LabVIEW also allows functions (VIs) to return multiple values - something I haven't seen in any other language, and which I think would limit the options for higher-order functions.

 

This isn't problematic. VIs that return multiple values are analogous to functions that return tuples.

 

This is something that needs to be deeply engrained in the language itself.

 

This is true for some functional concepts like purity and referential transparency. But there are other immensely useful language features common in functional languages that could be implemented in LabVIEW without breaking current language features, like parametric polymorphism, disjoint unions, lambdas, and partial application.

 

It reminds me of (I think, can't be bothered to look it up) an XKCD comic which had a caption along the lines of "functional programming combines the power and elegance of abstract maths with the ease of understanding of abstract maths".

 

I think generic higher-order functions and laziness are what make Haskell difficult to reason about for beginners. I don't think laziness would ever be a good fit for LabVIEW and developers could avoid generic higher-order VIs if they didn't like them.

[ShaunR]

LabVIEW also allows functions (VIs) to return multiple values - something I haven't seen in any other language, 

Python?

Edited December 25, 2014 by ShaunR

[Rolf Kalbermatter]

Python?

 

Lua definitely too. It makes a clear distinction between input parameters and function return values. No passed by reference parameter values to return information from a function!

 

Of course once you pass in objects like tables there is always the possibility for side effects from changes inside the function to these objects.

[ned]

This isn't problematic. VIs that return multiple values are analogous to functions that return tuples.

Just ran across this http://fsharpforfunandprofit.com/rop/ (Railway Oriented Programming) in which the author represents normal input and an error condition as two railway tracks, with a result that looks like LabVIEW's error wire. Made me think of this discussion. In the presentation, errors are handled as Discriminated Unions, not as tuples, where the value can either be Success (of a value) or Failure (of an error). Interesting to see a functional error-handling implementation that resembles the LabVIEW approach.

[Testy]

Just ran across this http://fsharpforfunandprofit.com/rop/ (Railway Oriented Programming) in which the author represents normal input and an error condition as two railway tracks, with a result that looks like LabVIEW's error wire. Made me think of this discussion. In the presentation, errors are handled as Discriminated Unions, not as tuples, where the value can either be Success (of a value) or Failure (of an error). Interesting to see a functional error-handling implementation that resembles the LabVIEW approach.

 

This is one example of how awesome discriminated unions would be in LabVIEW. They would force you to handle the possibility of an error.

 

They've actually been proposed on the idea exchange and unfortunately got shot down:

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/New-Enum-Class-Primitive-quot-The-Defined-Enum-quot-with/idi-p/1904525

 

I think F# is has a lot of good examples of functional features that could be implemented in LabVIEW: generic programming, discriminated unions, lambdas, and partial application. What I think makes F# such a good example of what LabVIEW could do is that it implements these features while allowing side effects, supporting OOP, and other non-functinal features just like LabVIEW.

[ShaunR]

Hi guys,

 

I've just started to play around with Haskell 

 

 

Couldn't resist