Labview in Erlang
Sun Aug 13 21:44:30 BST 2006
Introduction
Labview is the common programming language used for data acquisition in the experimental sciences (although Matlab is also very popular). The main selling point of Labview is the ability to write programs in a graphical programming language where functions are "virtual instruments" with defined inputs and outputs joined together by wires. This allows for "data flow" based programming where the output of a virtual instrument is calculated as soon as all of the inputs are available.
Initial thoughts
In Erlang the input and output messages can be represented by messages, and the virtual instruments by processes. The tricky thing is to represent the data flow of the input messages so that the process calculates the outputs only when all of the input messages have arraived. Take a simple example of a process that requires three data inputs to calculate its output. One approach would be to use a finite state machine with an accepting route consisting of a three state transition leading to the final calculation state. The first receiving state accepts any of the named inputs and then goes to the next receiving state. This next receiving state accepts any input except inputs from the first input channel (which remain unread on the message stack). The final receiving state only accepts inputs on the remaining channel.
Something like:
accept_one({In1, In2, In3}) ->
receive
{In1, Val} ->
accept_two([{In1, Val}], {In2, In3});
{In2, Val} ->
accept_two([{In2, Val}], {In1, In3});
{In3, Val} ->
accept_two([{In3, Val}], {In1, In2})
end.
accept_two(Vals, {In1, In2}) ->
receive
{In1, Val} ->
accept_three([{In1, Val} | Vals], In2);
{In2, Val} ->
accept_three([{In2, Val} | Vals], In1)
end.
accept_three(Vals, In) ->
receive
{In, Val} ->
calc([{In, Val} | Vals])
end.
calc(Vals) ->
% do stuff
% ...
accept_one(?Inputs). % Macro defining inputs
Rethink (1)
The above is the basic idea, now is the time to extend that idea to something useful.
Firstly, a dictionary or some O(1) access data type is probably a better choice for passing around the accumulated input data.
Secondly, it would be very useful to generate the code for the input variable dataflow handling automatically. This means define the input parameters of the virtual instrument should be defined in some simple syntax which is then compiled into the boilerplate code for the input data handling states. This could be as simple as a function definition eg viName(name1,name2,name3). Alternatively, why not just write the desired behaviour of the virtual instrument as an Erlang function, and generate the input data flow handling from this?
Rethink (2)
This is only half the task of creating a Labview-like dataflow oriented programming language. The other half is connecting the virtual instruments together. To accomplish this the virtual instruments must display the names of the intruments themselves and their inputs and outputs. Describe the system as a whole by the connections between inputs and outputs of different virtual instruments (one output can drive multiple inputs but only a single source can drive an input).
Also, how to construct larger virtual instruments out of multiple small virtual instruments connected together?
[permlink]