parent
8248024277
commit
2387d70266
@ -0,0 +1,195 @@ |
||||
--- |
||||
title: >- |
||||
Conditionals in Ginger |
||||
description: >- |
||||
Some different options for how "if" statements could work. |
||||
series: ginger |
||||
tags: tech |
||||
--- |
||||
|
||||
In the [last ginger post][last] I covered a broad overview of how I envisioned |
||||
ginger would work as a language, but there were two areas where I felt there was |
||||
some uncertainty: conditionals and loops. In this post I will be focusing on |
||||
conditionals, and going over a couple of options for how they could work. |
||||
|
||||
[last]: {% post_url 2021-01-09-ginger %} |
||||
|
||||
## Preface |
||||
|
||||
By "conditional" I'm referring to what programmers generally know as the "if" |
||||
statement; some mechanism by which code can do one thing or another based on |
||||
circumstances at runtime. Without some form of a conditional a programming |
||||
language is not Turing-complete and can't be used for anything interesting. |
||||
|
||||
Given that it's uncommon to have a loop without some kind of a conditional |
||||
inside of it (usually to exit the loop), but it's quite common to have a |
||||
conditional with no loop in sight, it makes more sense to cover conditionals |
||||
before loops. Whatever decision is reached regarding conditionals will impact |
||||
how loops work, but not necessarily the other way around. |
||||
|
||||
For the duration of this post I will be attempting to construct a simple |
||||
operation which takes two integers as arguments. If the first is less than |
||||
the second then the operation returns the addition of the two, otherwise the |
||||
operation returns the second subtracted from the first. In `go` this operation |
||||
would look like: |
||||
|
||||
```go |
||||
func op(a, b int) int { |
||||
if a < b { |
||||
return a + b |
||||
} |
||||
return b - a |
||||
} |
||||
``` |
||||
|
||||
## Pattern 1: Branches As Inputs |
||||
|
||||
The pattern I'll lay out here is simultaneously the first pattern which came to |
||||
me when trying to figure this problem out, the pattern which is most like |
||||
existing mainstream programming languages, and (in my opinion) the worst pattern |
||||
of the bunch. Here is what it looks like: |
||||
|
||||
``` |
||||
in -lt-> } -if-> out |
||||
} |
||||
in -add-> } |
||||
} |
||||
in -1-> } } |
||||
in -0-> } -sub-> } |
||||
|
||||
``` |
||||
|
||||
The idea here is that the operation `if` could take a 3-tuple whose elements |
||||
are, respectively: a boolean, and two other edges which won't be evaluated until |
||||
`if` is evaluated. If the boolean is true then `if` outputs the output of the |
||||
first edge (the second element in the tuple), and otherwise it will output the |
||||
value of the second edge. |
||||
|
||||
This idea doesn't work for a couple reasons. The biggest is that, if there were |
||||
multiple levels of `if` statements, the structure of the graph grows out |
||||
_leftward_, whereas the flow of data is rightwards. For someone reading the code |
||||
to know what `if` will produce in either case they must first backtrack through |
||||
the graph, find the origin of that branch, then track that leftward once again |
||||
to the `if`. |
||||
|
||||
The other reason this doesn't work is because it doesn't jive with any pattern |
||||
for loops I've come up with. This isn't evident from this particular example, |
||||
but consider what this would look like if either branch of the `if` needed to |
||||
loop back to a previous point in the codepath. If that's a difficult or |
||||
confusing task for you, you're not alone. |
||||
|
||||
## Pattern 2: Pattern Matching |
||||
|
||||
There's quite a few languages with pattern matching, and even one which I know |
||||
of (erlang) where pattern matching is the primary form of conditionals, and the |
||||
more common `if` statement is just some syntactic sugar on top of the pattern |
||||
matching. |
||||
|
||||
I've considered pattern matching for ginger. It might look something like: |
||||
|
||||
{% raw %} |
||||
``` |
||||
in -> } -switch-> } -> {{{A, B}, _}, ({A,B}-lt->out)} -0-> } -add-> out |
||||
in -1-> } -> } } -1-> } -sub-> out |
||||
in -0-> } |
||||
``` |
||||
{% endraw %} |
||||
|
||||
The `switch` operation posits that a node can have multiple output edges. In a |
||||
graph this is fine, but it's worth noting. Graphs tend to be implemented such |
||||
that edges to and from a node are unordered, but in ginger it seems unlikely |
||||
that that will be the case. |
||||
|
||||
The last output edge from the switch is the easiest to explain: it outputs the |
||||
input value to `switch` when no other branches are able to be taken. But the |
||||
input to `switch` is a bit complex in this example: It's a 2-tuple whose first |
||||
element is `in`, and whose second element is `in` but with reversed elements. |
||||
In the last output edge we immediately pipe into a `1` operation to retrieve |
||||
that second element and call `sub` on that, since that's the required behavior |
||||
of the example. |
||||
|
||||
All other branches (in this switch there is only one, the first branch) output |
||||
to a value. The form of this value is a tuple (denoted by enclosed curly braces |
||||
here) of two values. The first value is the pattern itself, and the second is an |
||||
optional predicate. The pattern in this example will match a 2-tuple, ignoring |
||||
the second element in that tuple. The first element will itself be matched |
||||
against a 2-tuple, and assign each element to the variables `A` and `B`, |
||||
respectively. The second element in the tuple, the predicate, is a sub-graph |
||||
which returns a boolean, and can be used for further specificity which can't be |
||||
covered by the pattern matching (in this case, comparing the two values to each |
||||
other). |
||||
|
||||
The output from any of `switch`'s branches is the same as its input value, the |
||||
only question is which branch is taken. This means that there's no backtracking |
||||
when reading a program using this pattern; no matter where you're looking you |
||||
will only have to keep reading rightward to come to an `out`. |
||||
|
||||
There's a few drawbacks with this approach. The first is that it's not actually |
||||
very easy to read. While pattern matching can be a really nice feature in |
||||
languages that design around it, I've never seen it used in a LISP-style |
||||
language where the syntax denotes actual datastructures, and I feel that in such |
||||
a context it's a bit unwieldy. I could be wrong. |
||||
|
||||
The second drawback is that pattern matching is not simple to implement, and I'm |
||||
not even sure what it would look like in a language where graphs are the primary |
||||
datastructure. In the above example we're only matching into a tuple, but how |
||||
would you format the pattern for a multi-node, multi-edge graph? Perhaps it's |
||||
possible. But given that any such system could be implemented as a macro on top |
||||
of normal `if` statements, rather than doing it the other way around, it seems |
||||
better to start with the simpler option. |
||||
|
||||
(I haven't talked about it yet, but I'd like for ginger to be portable to |
||||
multiple backends (i.e. different processor architectures, vms, etc). If the |
||||
builtins of the language are complex, then doing this will be a difficult task, |
||||
whereas if I'm conscious of that goal during design I think it can be made to be |
||||
very simple. In that light I'd prefer to not require pattern matching to be a |
||||
builtin.) |
||||
|
||||
The third drawback is that the input to the `switch` requires careful ordering, |
||||
especially in cases like this one where a different value is needed depending on |
||||
which branch is taken. I don't consider this to be a huge drawback, as |
||||
encourages good data design and is a common consideration in other functional |
||||
languages. |
||||
|
||||
## Pattern 3: Branches As Outputs |
||||
|
||||
Taking a cue from the pattern matching example, we can go back to `if` and take |
||||
advantage of multiple output edges being a possibility: |
||||
|
||||
``` |
||||
in -> } -> } -if-> } -0-> } -add-> out |
||||
in -1-> } -> } } } -1-> } -sub-> out |
||||
in -0-> } } |
||||
} |
||||
in -lt-> } |
||||
``` |
||||
|
||||
It's not perfect, but I'd say this is the nicest of the three options so far. |
||||
`if` is an operation which takes a 2-tuple. The second element of the tuple is a |
||||
boolean, if the boolean is true then `if` passes the first element of its tuple |
||||
to the first branch, otherwise it passes it to the second. In this way `if` |
||||
becomes kind of like a fork in a train track: it accepts some payload (the first |
||||
element of its input tuple) and depending on conditions (the second element) it |
||||
directs the payload one way or the other. |
||||
|
||||
This pattern retains the benefits of the pattern matching example, where one |
||||
never needs to backtrack in order to understand what is about to happen next, |
||||
while also being much more readable and simpler to implement. It also retains |
||||
one of the drawbacks of the pattern matching example, in that the inputs to `if` |
||||
must be carefully organized based on the needs of the output branches. As |
||||
before, I don't consider this to be a huge drawback. |
||||
|
||||
There's other modifications which might be made to this `if` to make it even |
||||
cleaner, e.g. one could make it accept a 3-tuple, rather than a 2-tuple, in |
||||
order to supply differing values to be used depending on which branch is taken. |
||||
To me these sorts of small niceties are better left to be implemented as macros, |
||||
built on top of a simpler but less pleasant builtin. |
||||
|
||||
## Fin |
||||
|
||||
If you have other ideas around how conditionals might be done in a graph-based |
||||
language please [email me][email]; any and all contributions are welcome! One |
||||
day I'll get around to actually implementing some of ginger, but today is not |
||||
that day. |
||||
|
||||
[email]: mailto:mediocregopher@gmail.com |
Loading…
Reference in new issue