[Proposal] Make use of the Fabric of 2d Space

[gregsn]

Alright. I have to admit that the headline is clickbait. I needed to somehow make the quest #15 sound more complicated and the proposal more genius. While it isn't.

The proposal is simple:

• If two nodes don't depend on each other (via data-flow), the node that is above of the other is called first (and if on the same height, the one to the left is called first).

That way we don't have to rely on new ways of expression (e.g. execution order links #17). If we'd introduce those explicit ordering helpers, we'd still need to tell the user that the execution order is undefined for the case that you don't use those explicit ordering constructs.

Undefined doesn't mean random

(and "undefined" probably currently means that nodes get preferred that got added to the patch earlier; which is like saying: it is not defined, but deterministic, and yes, it is determined in some non-visual way.)

Positioning + data-flow = implicit execution order links

We should end up with one perfectly defined order. We now could offer a patch editor option that visualizes the found ordering via arrows. And these are implicit execution order links. In a more advanced proposal, you'd be able to pin those and make them explicit (#17). And by that be able to freely move nodes around and be sure that the execution order stays the same as it is now.

In another mode, we could only show those implicit execution order links that stem from positioning. (Reasoning here: the dataflow dependencies already are visualized via lines).

Easy to understand

• See screenshot of quest #15: What we would like to express: Make sure that the region CallingYouWhenInGoodMood gets executed first. Just putting it first (above) the Data node feels natural.
• If you'd have R & S nodes (2020.2 actually ships them), putting the S above the R also sounds reasonable.

Critique: too Fragile when refactoring?

I will give you the opportunity to fill out this section. I am just too happy with the intrinsic properties of 2d space.

Doesn't contradict other approaches

As shown above we could come up with explicit execution order links later on and combine it with this approach.

The language and the UI don't have to be changed

We just change the specification and probably 12 lines in the code.

TODO

• Reason about regions (shouldn't be an issue)
• Reason about setter and getters. The assignments are expressed by the links. So is it about the position of the links? Probably not. We just use the pad position. Edit: this is impossible. Reading from fields is always done before anything else. Writing to fields is always done at the end. See #18 The fact that we ourselves get confused makes this proposal more important: #20 Are there other things that need sorting that I left out?

[gregsn]

Cons:

• this is a breaking change. Some rare patches might need to get fixed.
• as long as there is no visualization of the implicit execution order links a user might feel uncomfortable when moving nodes around. It's an action that shouldn't make you feel uncomfortable.

[gregsn]

this	will turn into this

according to the specification. That doesn't sound too clever with regards to minimizing the amount of EOLs... :(

[gregsn]

It also doesn't sound too clever regarding the use of CPU caches. Both branches (left/right) might operate on more complex data than in this stupid example and by that come with the need to access certain data on the heap. Typically switching between unrelated computations doesn't sound like a good default ordering idea for when no explicit hints got placed by the user.

[gregsn]

this is a too bold proposal. it leaves the compiler no choice but to order the calls in a potentially inefficient way.