Which Direction Should Arrows Point?

Axioms

In Western writing systems we place the first element of a list on the left and the last element on the right. Therefore, the list consisting of the first seven natural numbers in increasing order would be:

The second element of this list is 1, not 5. This convention is thousands of years old; it is not going to change anytime soon.

Most programming languages follow this convention in their “list literal” syntax; for example, the Haskell syntax for the list above is:

or else

Consequences

Given that we cannot change the convention above, it seems that all other arbitrary choices should be made in the manner most consistent with the already-fixed decisions which cannot be revised (even though they too are merely older, but just as arbitrary!).

If we think of the items of a list as being a stream “in motion”, then clearly they are flowing from the right to the left. When thought of this way, the digits pass through any fixed point in space in proper sequential order. If the data flow from left to right, they will pass through any given fixed point in space in the reverse order.

Therefore: whenever one draws a diagram whose arrows could possibly be interpreted as carrying streams of data, the diagram should be drawn so that the arrows are oriented predominantly leftward and upward. Of course, this rule only applies in contexts where the surrounding prose uses a Western language.

Benefits

This convention seems unusual at first, but it isn't hard to get used to and has many benefits:

• The normal composition operator f . g puts its arguments in the “diagrammatic” order. This eliminates most of the reasons for having the “reversed” composition operator g ; f, thereby avoiding the need to choose one or the other.

• This convention is consistent with writing arguments to the right of the function being applied to them: f(x). That convention is probably only a few hundred years old, so it takes a back seat to the direction-of-writing convention, but it is still pleasant to find that we happen to be consistent with it.

  The “reversed” composition operator only makes sense if you write your arguments to the left of the function being applied so that x(g;f)=(x g)f; otherwise (g;f)(x)=f(g(x)) forces you to change the order of the function bodies when changing notation, which creates confusion. Those who advocate the “reversed” composition order mysteriously fail to advocate writing arguments to the left of the function being applied; I cannot explain this.

• Diagrams in the parsing literature becomes far simpler. You can think of the input string as being written on a tape which extends off to the right of the parsing machine; the machine consumes this tape and emits another tape to its left.

  The parser's stack can be drawn coming out the bottom of the machine or, in the case of GLR or packrat parsers, out the left hand side (“parallel” to the output stream but not necessarily flowing at the same rate). This resolves what I consider to be a major difficulty in making the LR parsing literature accessible; much of it shows stacks and trees growing to the right, which means that their nodes are in reverse-textual order.

• Lastly, establishing the convention that arrows point upwards is consistent with the interpretation of a partially ordered set as a category in which there is a morphism from each object to those greater than it. When the objects are arranged so that “larger” objects appear above “smaller” objects, the arrows point upward. In the special case of a tree (a poset in which every principal down-set is well-ordered), the tree “grows upward” as it should (long-established convention in mathematics, irritatingly disregarded by computer scientists).

Drawbacks

• When performing arithmetic, one writes digits of greater import to the left of those of lesser import. This is yet another multiple-thousand-year-old tradition, and furthermore is shared with Middle Eastern cultures.

  Digit-serial arithmetic is typically performed least-significant-digit-first when addition and subtraction are the most important operations. I feel that when the data being represented are known to be digits of a number being processed in digit-serial fashion, one should make an exception to the rule above and draw diagrams with the digits flowing from right to left.

rendered from WIX