Nodes should be read from lowest to highest

[felipesabino]

The parser implementation reads nodes left to right instead of lowest to highest (as original design intends)

The program starts at the main branch and moves upwards. It then follows the lowest branch it finds off of the main branch. It then follows that branch, choosing always the lowest possible branch first. Finally, when the lowest possible branches have been explored, it returns the the branch from which the current branch stems, and explores the next lowest branches that have not been followed yet.

This text is ambiguous in the sense of what lowest and highest means.

If it means whatever comes first when following the main branch, how should a tie be handled when it is possible to move both left and right?

Given the example bellow

1   2
 \ /    4
  \ 3 /
   \|/
    |

Current implementation

The current implementation of the example above would add 1, 2, 4 and 3 to the stack as it parses the left-most branch until the end, comes back to next possibility and pares the right-most and only then follows the main branch

lowest means shortest

Other possible interpretation is that lowest means shortest. So, considering the shortest path to reach a leaf, which can be as like doing a BFS to visit the tree nodes, so this case could result in the stack as 3, 4, 1 and 4 OR 3, 4, 2 ,1 depending on how you decide left and right ties precede each other.

ambiguity of the original design

The original Hello, World! example seems to not follow the lowest means shortest rule strictly, seeming to favor the left branch as it was the lowest in the main branch. But how would it handle a tie?

In the example above it is not clear how the original tree traversing design expects the elements to be added to the stack. (Should two branches in the same level at the main branch be considered a parsing error?)

[somebody1234]

Okay so... from what I can tell:
The docs say

[the branches] are executed from lowest to highest, left to right.

And judging by the Hello, World! example, this is how it works:

1. Go up trunk (I will call it this because it appears to be specialcased compared to all other branches.) until a branch is reached.
2. If there is a left branch, go up that branch.
3. When branch splits, go down all paths (BFS); execute leaves left to right, bottom to top.
4. Repeat steps 2-3 for right branch.
5. Go to step 1 until the end of the trunk is reached.
6. Execute the leaf on the top of the trunk (if any (?))

Note that the leaves are diagonal from the branches (I'm assuming directly above as well if vertical branches exist) but can also extend sideways.
However, valid arrangements of leaves seem to be awfully ambiguous (in fact, I think it might possibly be a specification error), so I think the above should be sufficient?

[felipesabino]

[the branches] are executed from lowest to highest, left to right.

In my understanding this part of the doc refereed to the leaves, not branches

Leaves may be placed only at the end of branches. They are executed from lowest to highest, left to right.

But I guess it can be extrapolated.

Thanks for the feedback, I think this approach is valid and consistent with my previous choice to have a left-right precedence.

I am leaving this open until I get the chance to update the parser

[somebody1234]

Well, I think maybe it applies to both, branch height being measured by the distance up the trunk.

[somebody1234]

In that case, looking at the examples, technically you can use something like a fill algorithm to find groups of leaves (connected would also mean diagonally connected), and execute that bottom to top, left to right. It does work for the big group at the top of the Hello, World!, but not sure if that is intended behavior.