1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
|
---
title: >-
Conditionals in Ginger, Errata
description: >-
Too clever by half.
series: ginger
tags: tech
---
After publishing the last post in the series I walked away from my computer
feeling that I was very clever and had made a good post. This was incorrect.
To summarize [the previous post][prev], it's not obvious which is the best way
to structure conditionals in a graphical programming language. My favorite
solution looked something like this:
```
in -> } -> } -if-> } -0-> } -add-> out
in -1-> } -> } } } -1-> } -sub-> out
in -0-> } }
}
in -lt-> }
```
Essentially an `if` operator which accepts a value and a boolean, and which has
two output edges. If the boolean is true then the input value is sent along the
first output edge, and if it's false it's sent along the second.
This structure is not possible, given the properties of ginger graphs that have
been laid out in [other posts in the series][other].
## Nodes, Tuples, and Edges
A ginger graph, as it has been presented so far, is composed of these three
elements. A node has a value, and its value is unique to the graph; if two nodes
have the same value then they are the same node. Edges connect two nodes or
tuples together, and have a value and direction. Tuples are, in essence, a node
whose value is its input edges.
The `if` operation above lies on an edge, not a node or tuple. It cannot have
multiple output edges, since it cannot have any edges at all. It _is_ an edge.
So it's back to the drawing board, to some extent. But luckily I've got some
more ideas in my back pocket.
## Forks and Junctions
In an older conception of ginger there was no tuple, but instead there were
forks and junctions. A junction was essentially the same as a tuple, just named
differently: a node whose value is its input edges. A fork was just the
opposite, a node whose value is its output edges. Junctions and forks naturally
complimented each other, but ultimately I didn't find forks to be useful for
much because there weren't cases where it was necessary to have a single edge be
split across multiple output edges directly; any case which appeared to require
a fork could be satisfied by directing the edge into a 1-tuple and using the
output edges of the 1-tuple.
But now we have such a case. The 1-tuple won't work, because the `if` operator
would only see the 1-tuple, not its edges. It could be supposed that the graph
interpreter could say that an `if` operation must be followed by a 1-tuple, and
that the 1-tuple's output edges have a special meaning in that circumstance. But
making the output edges of a 1-tuple have different meaning in different
circumstances isn't very elegant.
So a fork might be just the thing here. For the example I will represent a
fork as the opposite of a tuple: a vertical column of `{` characters.
```
in -> } -> } -if-> { -0-> } -add-> out
in -1-> } -> } } { -1-> } -sub-> out
in -0-> } }
}
in -lt-> }
```
It _looks_ elegant, which is nice. I am curious though if there's any other
possible use-case where a fork might be useful... if there's not then it seems
odd to introduce an entire new element just to support a single operation. Why
not just make that operation itself the new element?
## Switch it Up
In most conceptions of a flowchart that I've seen a conditional is usually
represented as a node with a different shape than the other nodes (often a
diamond). Ginger could borrow this idea for itself, and declare a new graph
element, alongside nodes, tuples, and edges, called a switch.
Let's say a switch is simply represented by a `-<>`, and acts like a node in all
aspects except that it has no value and is not unique to the graph.
The example presented in the [previous post][prev] would look something like
this:
```
in -> } -> } -<> -0-> } -add-> out
in -1-> } -> } } -1-> } -sub-> out
in -0-> } }
}
in -lt-> }
```
This isn't the _worst_. Like the fork it's adding a new element, but that
element's existence is required and its usage is very specific to that
requirement, whereas the fork's existence is required but ambiguously useful
outside of that requirement.
On the other hand, there are macros to consider...
## Macrophillic
Ginger will certainly support macros, and as alluded to in the last post I'd
like even conditional operations to be fair game for those who want to construct
their own more complex operators. In the context of the switch `-<>` element,
would someone be able to create something like a pattern matching conditional?
If the builtin conditional is implemented as a new graph element then it seems
that the primary way to implement a custom conditional macro will also involve a
new graph element.
While I'm not flat out opposed to allowing for custom graph elements, I'm
extremely skeptical that it's necessary, and would like it to be proven
necessary before considering it. So if we can have a basic conditional, _and_
custom conditional macros built on top of the same broadly useful element, that
seems like the better strategy.
So all of that said, it seems I'm leaning towards forks as the better strategy
in this. But I'd like a different name. "Fork" was nice as being the compliment
of a "junction", but I like "tuple" way more than "junction" because the term
applies well both to the structural element _and_ to the transformation that
element performs (i.e. a tuple element combines its input edges' values into a
tuple value). But "tuple" and "fork" seem weird together...
## Many Minutes Later...
A brief search of the internet reveals no better word than "fork". A place
where a tree's trunk splits into two separate trunks is called a "fork". A
place where a river splits into two separate rivers is called a "fork".
Similarly with roads. And that _is_ what's happening, from the point of view of
the graph's structure: it is an element whose only purpose is to denote multiple
outward edges.
So "fork" it is.
## Other considerations
A 1-tuple is interesting in that it acts essentially as a concatenation of two
edges. A 1-fork could, theoretically, do the same thing:
```
a -foo-> } -bar-> b
c -far-> { -boo-> d
```
The top uses a tuple, the bottom a fork. Each is, conceptually, valid, but I
don't like that two different elements can be used for the exact same use-case.
A 1-tuple is an established concept in data structures, so I am loath to give it
up. A 1-fork, on the other hand, doesn't make sense structurally (would you
point to any random point on a river and call it a "1-fork"?), and fork as a
whole doesn't really have any analog in the realm of data structures. So I'm
prepared to declare 1-forks invalid from the viewpoint of the language
interpreter.
Another consideration: I already expect that there's going to be confusion as to
when to use a fork and when to use multiple outputs from a node. For example,
here's a graph which uses a fork:
```
a -> { -op1-> foo
{ -op2-> bar
```
and here's a graph which has multiple outputs from the same node:
```
a -op1-> foo
-op2-> bar
```
Each could be interpreted to mean the same thing: "set `foo` to the result of
passing `a` into `op1`, and set `bar` to the result of passing `a` into `op2`."
As with the 1-tuple vs 1-fork issue, we have another case where the same
task might be accomplished with two different patterns. This case is trickier
though, and I don't have as confident an answer.
I think an interim rule which could be put in place, subject to review later, is
that multiple edges from a node or tuple indicate that that same value is being
used for multiple operations, while a fork indicates something specific to the
operation on its input edge. It's not a pretty rule, but I think it will do.
Stay tuned for next week when I realize that actually all of this is wrong and
we start over again!
[prev]: {% post_url 2021-03-01-conditionals-in-ginger %}
[other]: {% post_url 2021-01-09-ginger %}
|
