That sounds completely reasonable. However, we try not to call Luna a “dataflow language” just because “dataflow” term is often used to describe systems with some design decisions that are much more limited than what Luna provides, see for example: https://en.wikipedia.org/wiki/Dataflow_programming .
In the Wikipedia we can read
An operation runs as soon as all of its inputs become valid. Thus, dataflow languages are inherently parallel and can work well in large, decentralized systems.
Luna is much more than that. Let me explain.
First of all, Luna is a lazy language. It will not evaluate anything until it is needed. Even if you provide an array with million of elements and then make some operation on it (for example sum pairs of elements next to each other), only the needed part of the data will be computed. Luna works the same way as Haskell here, so it provides thunks and very efficient runtime laziness behavior. (As a side note: we currently do not support disabling laziness for particular data / functions, but we will support it soon). Moreover, what does a “connection” between Luna nodes mean, depends on the library. In other words - you can create a library, which re-defines what connection means while using the library! (In Haskell terms, connections are just monadic bindings). So when you open a new Luna project, connection is just a binding between variables (like in standard functional programming language). However, if you use libraries, like a streaming one (see the crypto currency demo scene), connections can become “pipes” sending data between concurrently executing nodes - which is a library level dataflow implementation!
To sum this up - you can definitely create libraries in Luna which will allow you to think about it in terms of dataflow (or flowbased) programming, however Luna gives you much more general mechanisms. In its most general form it is a general purpose, purely functional language with non-strict semantics.
Does it make sense to you ?