I’m reading about visual programming languages these days. So I’ve thought up two “paradigms”. In both of them, you have one start point, and several end points.
Now, you could either begin at the start point or move in reverse from the end points (the order of end points is known).
Beginning from the start point feels weird, because you can have “splits” in the data flow. Say, if I have an interger, and this integer is needed by two functions simultaenously. Bad. I don’t want to get into concurrent coding. Atleast not yet. Or should I?
Beginning at the end points feels much better. You start at the first end point. Check whatever is needed, and evaluate that. I believe this is the lazy evaluation. But the problem comes when you have multiple inputs. How do you decide the order in which to evaluate the inputs?
Can you point me to some articles/papers/something on the internet. Or mabye tell me a few keywords to look for?
If I get what you mean, using the same integer in two functions, is exactly that: you just use it twice, no need to bring concurrency in. If the ‘implementation’ you were thinking about destroyed input values, you could take a copy before using it.
would become:
But there’s no need of concurrency in order to evaluate the graph. You can just evaluate ‘parallel’ branches left to right (as indicated by the A-B-C-… labelling – see also here).
Top-down (aka from start to end), left-to-right feels more natural than bottom-up, provided bottom-up actually has a well defined meaning. Regarding the latter point, assuming you do have results for the program, you can’t always compute the inputs: think about what happens when
funXXXare not injective (for examplefun1(x) = x*x) and thus not invertible.I hope I’m not completely misinterpreting your train of thought.