Polymorphic types

[LAVA 1.0 Content]

My third post for Santa this friday. This is really something I've been wanting to see in LabVIEW for some time now.

Polymorpic types

First of all, I'd like to see polymorphic types. What I mean with this is the following. One should be able to define front panel terminals that are of multiple types simultanously. These terminals would accept all these types of data. Wire propagating from such a terminal could be connected to any node that would accept at least the same types, but could also accept some more types.

One can implement such a polymorphic types in a bit similar fashion as enums or arrays are implemented. A polymorphic type controller would be an "type-array" each element of which would be a type specifier. One could also drop another polymorphic type-array into such array so that the resulting polymorphism would include all the items of the array itself and all its subarrays and their subarrays and so on. The "type-array" would be structurally a tree and the polymorphic type of such a tree would be defined by flattening the tree into a set of all the nodes in the tree.

Type classes

Types should form hierarchies, that is type classes. For example Integer and Floating would be subtypes of general class Number. Furthermore I32 and I16 would be subtypes of Integer type. You could define that your terminal is of type Integer and would therefore accept both I32 and I16 inputs without coercion.

The type classes shold in the beginning be built-in only. That is, user couldn't add new members to built-in type classes. Later on however, users should be able to extend type classes by defining own type that belong to certain type class. Type classes are exactly specified by requiring that certain built-in operations are defined for the type. For example a type of class number must have addition, substraction and multiplication defined. Type of class Floating should in addition have division operation defined.

Type classes, polymorphic types, type propagation and dynamic dispatching

Type propagation of polymorphic types and type classes is somewhat similar issue to type propagation of LVOOP classes. When you wire two DBLs to your "+" operation, you want the output to be DBL. That means that the correct instance of operations should be decided at run-time not compile time. Since the same type often propagates trough multiple subVIs and multiple nodes, not all of these need to be dynamically dispatched one-by-one. Rather a whole block depending only on one type can be dispatched as an entity. If the correct block to be dispatched depends on multiple types, then probably the safest thing to do is to call the correct operation one-by-one.

Roadmap

Now that we have defined polymorphic types and type-classes, we still need to add wires and extend types so that wires can propagate not only VI references but block-diagrams themselves. We also need totally stateless VIs, real recursion (without opening a VI reference first), local and global variables that can only be written once (i.e. they are also stateless), perhaps lazy evaluation and some kind of lamda calculus, type pattern matching similar to Haskell counterpart and we end up in a fully featured graphical functional programming language. Monads are not needed, since empty wires or something like error cluster can define the execution order for I/O and user interface operations. Loops can be used in dataflow version of functional programming language, as they do not require variables unlike loops in text based programming languages.

This kind of general purpose programming language would probably be the most advanced, easiest to use programming language in the world. It would be naturally multithreading and allow writing highly modular code. I think combining dataflow programming language and functional programming language results in a something really amazing.

It's a pity that I know National Instruments will never ever do this kind of general purpose programming language. Perhaps I do it myself. Anybody else interested in joining my... quite challenging effort tongue.gif

[crelf]

One should be able to define front panel terminals that are of multiple types simultanously. These terminals would accept all these types of data. Wire propagating from such a terminal could be connected to any node that would accept at least the same types, but could also accept some more types.

I don't think that would be too difficult to create, and I agree that it would be very useful.

You could define that your terminal is of type Integer and would therefore accept both I32 and I16 inputs without coercion.

I don't see how that's possible - as a dataflow language, data has a type, so if you act on it with another datatype coersion is going to happen (or it's going to break). Unless, that is, you're just considering this as an extendsion of the polymorphism that you talk about above...

It's a pity that I know National Instruments will never ever do this kind of general purpose programming language.

Hey hey hey - never say never! There's a bunch of great thinkers in the NI R&D world, and they've added some wonderful stuff - things that I had always wanted, but never expected from LabVIEW. Let's give them a little respect for that, and not write-off features because of your bias...