Graph name is confusing

[pettermahlen]

Specifically, there are issues around:

• the Trickle.call().with() sequence which creates a node but returns a graph.
• the fact that with() takes Graphs as parameters, but of course an edge in a graph goes from one node to another, not from a node to another graph.

[rouzwawi]

This is how I see it.

First, the definition of a nodes, edges and graphs

• A Node is an abstract entity that represents something
• Edges represent some relation between two nodes
• A Graph is the pair consisting of a set of Nodes and a set of Edges

Now in Trickle, I see Func as a node class. The call(Func).with(Graph*) sequence instantiates an actual Node from a Func and creates eventual Edges to other subgraphs. The difference from the above definition is that the Graph is not only the collection of nodes and edges, but it also points out the sink of the DAG. Meaning, our Graph type represents a single component DAG with a unique sink. V = {v1,v2,...}, E = {(vx,vy),(vz,vu),...}, S = vx where vx,vy,vz,vu ∈ V. It is this sink node you refer to when calling with(Graph*).

We only ever have references to a single Node and nothing else (the only case I would se an ambiguity between a Node and a Graph) when the Func used does not have any inputs. But this ambiguity does not contradict this entity being a Graph. A graph can just as well be V = {x}, E = ∅, S = x

[pettermahlen]

I think the name Graph is correct. A Trickle Graph is something that can be executed, perhaps requiring some inputs to be bound to values. I agree that individual Nodes are invisible, but I wonder which came first - the reasons why we're working with entire graphs at all times are:

• to make composing graphs easier, so you can have libraries, etc., defining graphs that can be used later on.
• to make it easier to come up with a palatable and typesafe API. The previous iteration with finallyCall to identify the sink node was much less elegant.

But I think it's a bit weird that what you happens when you do Trickle.call(func).with(graph) is to construct a new node and attach it as a new sink to the previous graph. The call().with() doesn't sound like you're doing graph manipulation. There may be a tradeoff here between highlighting the graph nature of what Trickle does and making the code read like a sequence of function invocations.

[spkrka]

I think call(Func).with(Graph*) is equivalent to creating a new node with directional edges to other nodes. It's thus odd that the other nodes are called Graph. I don't think the Func itself is a node, that's a property of the node.

[pettermahlen]

I agree Func and Node are different things, and I think both the views of the Func being a property of the Node and being the class of the Node make sense.

I also agree that what call(Func).with(Graph*) does is create a new node with edges to other nodes. Those nodes are the sink nodes of the graphs passed as arguments, not the graphs themselves. Using graphs as input parameters to .with() is convenient but not very clear/precise. Not returning the full Graph from a call().with().etc() sequence would probably be more inconvenient, I think. Also, it would mean users would have to deal with Nodes directly, adding one more type you need to understand.