I agree with the author, we need better primitives, if you need functionality now:

Major tools that exist today for partial structure traversal and focused manipulation:

- Optics (Lenses, Prisms, Traversals)

  Elegant, composable ways to zoom into, modify, and rebuild structures.

  Examples: Haskell's `lens`, Scala's Monocle, Clojure's Specter.

  Think of these as programmable accessors and updaters.

- Zippers

  Data structures with a "focused cursor" that allow local edits without manually traversing the whole structure.

  Examples: Huet’s original Zipper (1997), Haskell’s `Data.Tree.Zipper`, Clojure’s built-in zippers.

- Query Languages (for semantic traversal and deep search)

  When paths aren't enough and you need semantic conditionals:

    - SPARQL (semantic web graph querying)
    - Datalog (logic programming and query over facts)
    - Cypher (graph traversal in Neo4j)
    - Prolog (pure logic exploration)

  These approaches let you declaratively state what you want instead of manually specifying traversal steps.

    Account acc = getAccount();
    QVERIFY(acc.person.address.house == 20);

    auto houseLens = personL() to addressL() to houseL();
    std::function<int(int)> modifier = [](int old) { return old + 6; };
    
    Account newAcc2 = over(houseLens, newAcc1, modifier);

Tree traversal primitives (clojure.walk):

    (defn walk [inner outer form]
      (cond
       (list? form) (outer (with-meta (apply list (map inner form)) (meta form)))
       (instance? clojure.lang.IMapEntry form)
       (outer (clojure.lang.MapEntry/create (inner (key form)) (inner (val form))))
       (seq? form) (outer (with-meta (doall (map inner form)) (meta form)))
       (instance? clojure.lang.IRecord form)
         (outer (reduce (fn [r x] (conj r (inner x))) form form))
       (coll? form) (outer (into (empty form) (map inner form)))
       :else (outer form)))
    
    (defn postwalk [f form]
      (walk (partial postwalk f) f form))
    
    (defn prewalk [f form]
      (walk (partial prewalk f) identity (f form)))

Another reason why this perlisism holds:

    9. It is better to have 100 functions operate on one data structure than 10 functions on 10 data structures.

"Let's move on."

    (defn tree-seq
      "Returns a lazy sequence of the nodes in a tree, via a depth-first walk.
       branch? must be a fn of one arg that returns true if passed a node
       that can have children (but may not).  children must be a fn of one
       arg that returns a sequence of the children. Will only be called on
       nodes for which branch? returns true. Root is the root node of the
      tree."
      {:added "1.0"
       :static true}
       [branch? children root]
       (let [walk (fn walk [node]
                    (lazy-seq
                     (cons node
                      (when (branch? node)
                        (mapcat walk (children node))))))]
         (walk root)))

    (defn tree-seq-breadth
      "Like tree-seq, but in breadth-first order"
      [branch? children root]
      (let [walk (fn walk [node]
                   (when (branch? node)
                     (let [cs (children node)]
                       (lazy-cat cs (mapcat walk cs)))))]
        (cons root (walk root))))

Nathan Marz' talk on Specter (Clojure Library that decouples navigation from transformation) is must-watch if you deal with data: https://www.youtube.com/watch?v=VTCy_DkAJGk

I use it in every project for data navigation and transformation, and it's more performant than standard Clojure data manipulation, while retaining types (instead of coercing back from seqs).

E.g. if you have a map and you want to increment every value in the map: (require '[com.rpl.specter :as S])

``` (->> {:a 5, :b 6, :c 7} (S/transform [S/MAP-VALS] inc)) => {:a 6, :b 7, :c 8} ```

^ try to write that in normal clojure.

Now let's say you have a map of vectors and want to increment all of those? (->> {:a 5, :b 6, :c 7} (S/transform [S/MAP-VALS S/ALL] inc)) ;; note the navigator juts got another level of nesting => {:a [2 3], :b [4 5], :c [6 7]}works for all clj data types, and of course it has navigators for recursive walking .

It took me a while to get good at Specter, but it was worth it. I hear Rama uses Specter navigators internally.

That's "just" a particular kind of fancy iterator that you should be able to implement in any language with iterator support. Here's one in Python:

    # Expects:
    # Tuple of iterateOn where iterateOn can be None
    def fancyIt(init, *options):
        if init != None:
            yield(init)
            for f in options:
                newVal = f(init)
                yield from fancyIt(newVal, *options)

    class Tree:
        def __init__(self, val, left = None, right = None):
            self.val = val
            self.left = left
            self.right = right

        def left(self):
            return self.left
        def right(self):
            return self.right

    myTree = Tree(
        1,
        Tree(2,
             Tree(3),
             Tree(4, None, Tree(5))),
        Tree(6, None, Tree(7)))

    for node in fancyIt(myTree, Tree.left, Tree.right):
        print(node.val)

which prints the numbers 1 through 7 in order.

Breadth-first is slightly trickier, but only slightly trickier one time.

    for_tree(string x = ""; x.size() <= 8; x : {x+"a", x+"b", x+"c"}){
     print(x);
    }

    class StringIterator {
    public:
        using iterator_category = std::forward_iterator_tag;
        using value_type = std::string;
        using difference_type = std::ptrdiff_t;
        using pointer = const std::string*;
        using reference = const std::string&;

        StringIterator(bool begin = false) : is_end_(!begin) { if (begin) s_ = ""; }

        const std::string& operator*() const {
            if (is_end_) throw std::out_of_range("End iterator");
            return s_;
        }

        StringIterator& operator++() {
            if (is_end_) return *this;
            if (s_.size() < 8) return s_.push_back('a'), *this;
            while (!s_.empty() && s_.back() == 'c') s_.pop_back();
            if (s_.empty()) is_end_ = true;
            else s_.back() = s_.back() == 'a' ? 'b' : 'c';
            return *this;
        }

        StringIterator operator++(int) { auto tmp = *this; ++(*this); return tmp; }

        bool operator==(const StringIterator& other) const {
            return is_end_ == other.is_end_ && (is_end_ || s_ == other.s_);
        }

        bool operator!=(const StringIterator& other) const { return !(*this == other); }

    private:
        std::string s_;
        bool is_end_;
    };

    int main() {
        StringIterator begin(true), end;
        int count = 0;
        for (auto it = begin; it != end; ++it) ++count;
        std::cout << (count == 9841 ? "Pass" : "Fail") << std::endl;
        return 0;
    }

    def itWithStop(init, stop, *options):
        if init is not None and not stop(init):
            yield(init)
            for f in options:
                newVal = f(init)
                yield from itWithStop(newVal, stop, *options)

    for s in itWithStop("",
                       lambda x: len(x) > 2,
                       lambda x: x + "a",
                       lambda x: x + "b",
                       lambda x: x + "c"):
        print(s)

    module Tmp where

    iter :: forall a. (a -> Bool) -> [a -> a] -> a -> [a]
    iter p opts x = if p x then x:concatMap (iter p opts) (opts <*> [x]) else []


    ghci> :l tmp.hs
    [1 of 1] Compiling Tmp              ( tmp.hs, interpreted )
    Ok, one module loaded.
    ghci> iter (\x -> length x < 3) [(++ "a"), (++ "b"), (++ "c")] "" 
    ["","a","aa","ab","ac","b","ba","bb","bc",
     "c","ca","cb","cc"]

This is solved by iterators in C++. The idea of an iterators is to generalize the concept of a pointer —- something which refers to a location in your data structure.

For example the most basic operations of a pointer are to advance and dereference.

std::map is actually implemented as a tree. To iterator its members you can do

    for (cost auto &pair : map) 

The only requirement for your custom data structure to work is to implement begin() and end() which return iterators - “pointer like” objects.

    for (const auto&node: await depth_first_tree(node)) 

No, that seems like language bloat. Better to make your language have internal iterators, as then data structures can add their own logic that matches their need for iteration. Then special cases don't need additional syntax.

I think functional languages handle this nicely with Foldable or Traversable typeclasses: https://hackage.haskell.org/package/base-4.21.0.0/docs/Data-...

  class InOrderTreeIterator {
      Stack stack;
      TreeNode cursor;

      InOrderTreeIterator(TreeNode root) {
          cursor = root;
          s = new Stack;
      }

      bool hasNext() {
          return cursor != null || !stack.empty();
      }

      TreeNode next() {
          if (cursor != null) {
              while (cursor.left != null) {
                  stack.push(cursor);
                  cursor = cursor.left;
              }
          } else if (!stack.empty()) {
              cursor = stack.pop();
          } else {
              throw new NoSuchElementException();
          }
          TreeNode ret = cursor;
          cursor = cursor.right
          return ret;
      }
  }

    Iterable<TreeNode> inOrder(TreeNode node) sync* {
      if (node.left != null) yield* inOrder(node.left!);
      yield node;
      if (node.right != null) yield* inOrder(node.right!);
    }

I remember that I was using trees quite often last century, when I was writing programs in C. I seldom use tree or comparably complex data structures nowadays, when I almost only write web apps (mostly backend in Ruby or Python but some frontend in JS.) I'm bet that both Ruby and Python have plenty of trees written in C inside their interpreters. I do everything with arrays (lists) and hash tables (dicts) in Ruby and Python. Maybe a language construct for trees would be nice for lower level languages and almost out of scope for higher level ones.

The same from another angle: there are a lot of trees in the indices of SQL databases (example [1]) but we don't zoom in to that level of detail very often when defining our tables.

[1] https://www.postgresql.org/docs/current/btree.html

> "Why not just use recursive functions"

One great reason not to use recursive functions for traversing trees is that you can allocate your own stack data structure rather than relying on the call stack itself. In most languages/runtimes, the call stack has a maximum depth which limits the depth of trees you can process, usually on the order of thousands of stack frames.

Managing your own stack usually produces weirder looking code (personally I find "naive" recursive approaches more readable) - but having it as a first-class language feature could solve that!

To some extent, this seems like it's just a symptom of "writing iterators in C++ is harder than it ought to be". You don't need to have a tree in memory to build an iterator over it - folks write iterators over implicit data all the time.

Here's the range based for loop counterexample from the blog post, as a python generator:

  import itertools

  def iterate_tree():
      for length in range(1, 8):
          for combo in itertools.product("abc", repeat=length):
              yield ''.join(combo)

  for s in iterate_tree():
      print(s)

Pick a language that allows users to define their own control structures and test your idea in practise.

Candidates: Racket, Scheme, Rust.

The article's thesis relies on the idea that a genuinely primitive traversal action exists, in the way that a for-loop is primitive and widely applicable, or adding two floats is common enough to justify building it into the language (or processor).

But tree traversal doesn't have this universal property. There are too many methods and purposes for traversing a tree, sufficient that IMHO no single primitive embodiment could materially improve a language. Also, modern compilers efficiently break down high-level traversal code so well that expressing the idea at a high level incurs no serious penalty compared to having a primitive for that purpose, or a series of them.

Clojure has tree-seq https://clojuredocs.org/clojure.core/tree-seq

I'm not sure if it needs to be at the syntax level, but I think having built in standard library support for graphs (general trees) would help make graphs more common in programming. And seeing how powerful they are, I think that would be a good thing!

I explored this idea with gstd, a standard library for graphs inspired by the JS Array interface: https://github.com/cdrini/gstd/

That's what c++20 coroutines paired with c++23 generators are for. It's easy to define whatever traversal you want and then expose it as generic code.

https://godbolt.org/z/fnGzszf3j

I bet you could do something generic like this in languages that have deferred execution like C#'s IEnumerable. Something like

    foreach (Node node in EnumerateNodes(root, x => x != null, x => [x.Left, x.Right]))

where EnumerateNodes uses `yield return` (i.e. is a generator) and calls itself recursively. Though it'd probably be easier / better performance to write an implementation specific to each node type.

Tree traversal is an odd one to want to try and make primitive. There are a lot of hidden questions that you need to consider when traversing a tree. Would you want your syntax to indicate what order traversal? Should it indicate a way to control the extra memory that you allow for the common stack/queue used in basic traversal? If you have a threaded tree, should the syntax work without any extra memory usage?

One of the projects that I have only in my mind space is an Iversonian language with more data structures and the tools to easily navigate an traverse them. Trees, graphs, ... the sky is the limit. And with the power of notation as a tool of thought, and a pen interface, it would be fun to do whiteboard sessions that produced real code that could be executed as is.

OTOH I read/heard that the beauty of array languages is that they have few data types, but they can be easily worked on. So maybe the answer is not easier tree traversal primitives, but better literature/training on how to transform it in a more manageable data type.

Sometimes the answer is to adapt our vision to our world, sometimes the answer is to adapt the world to our vision.

In C#, you can implement an iterator method with the signature like this:

    public static IEnumerable<TNode> DepthFirstTraverse<TNode>(
        TNode root,
        Func<TNode, IEnumerable<TNode>> children
    )

You can then just ‘foreach’ over it.

This doesn’t require the whole tree to be in-memory. Optimal implementation would recurse via programmer-controlled stack (instead of language-controlled) to avoid nested iterators.

Here is a TypeScript version:

    function* traverseDepthFirst<T>(
        root: T,
        children: (parent: T) => Iterable<T>
    )

A similar approach should be possible in any language which supports iterators/generators.

The simplifying assumption that all tree nodes have the same type and the same function should be called on them seems unrealistic.

This kind of imperative iteration seems better served by the traditional visitor design pattern: more verbose (more explicit, not more complex) and more general.

This is interesting, but the syntax doesn't seem to have the right expressiveness for such a large change.

    for recursive (Node t = tree.root; t != NULL;) {
      puts(t.value);
      if (t.value == target) break;
      if (t.value == dontfollow) continue;
      if (t.left) continue t.left;
      if (t.right) continue t.right;
      }
    return t;

Regular 'break' is to really break out of the structure like a regular for, as regular 'continue' is to do the next iteration. But if continue has a value to recurse on, it reenters the for loop like a subroutine.

As a bonus, I think this is tail-call-optimization friendly.

It seems like this is grasping for languages to expose recursors[1] or induction principles. These factor out the structure of an inductive type (e.g. trees) and leave the caller to simply plug in the behavior to perform for each possible situation that might arise during traversal.

[1]: https://lean-lang.org/doc/reference/latest//The-Type-System/...

My thoughts on this are to add a third keyword alongside `break` and `continue` to loops that allow you to push another (loop) stack frame and descend into a tree-like data structure.

For exposition, lets seperate loop initialization from the rest, make `continue` mandatory to repeat the loop with another specified value (i.e. the loop implicitly ends without a continue) and lets say `descend` to recurse into the tree.

    sum = 0;
    loop (node = tree.root) {
        sum += node.value;
        if (node.left) descend node.left;
        if (node.right) descend node.right;
    }

Compare with a linear loop:

    sum = 0;
    loop (i = 0) {
        if (i >= array.length) break;
        sum += array[i];
        continue i + 1;
    }

The `descend` keyword differs from `continue` in that its more of a continuation - control flow will continue from that point once it is done.

You could make this more functional and less imperative (and I'd be surprised if such things don't exist as libraries in some functional languages). Yes ultimately we can transform this to recursive functions and compile it that way... but for imperative languages (especially those without closures) something like the above might be useful.

Arguably the above loops are _more_ imperative and less declaritive than the standard ones from the C family. You could add a functional twist by breaking with a value (which is the result of the overall `loop` expression).

When I went looking for this in Ruby, I eventually landed on RubyTree[1]. Being able to subclass the TreeNode makes everything so much friendlier. Sure, I could implement them myself, but getting converters to/from primitives for free is a lot off my mind. Would be nice to have it built into the language but honestly Ruby has a whole lot of stdlibs and default gems already.

1: https://github.com/evolve75/RubyTree

I think Java did the right thing by making tree shaped collections, since they’re iterable and that covers the for loop situation, but it doesn’t expose the tree structure, so you can’t tell if two nodes are siblings or relatives or indeed if they are even in the same tree.

But I think grafting those two together is the right answer, not inventing a new loop construct.

Trees are easy to write iterators for. DAGs are a bit harder and full graphs are an advanced interview question.

Excellent time to mention rust's `ControlFlow` enum which allows doing this exact sort of thing https://doc.rust-lang.org/std/ops/enum.ControlFlow.html

Not as ergonomic as a direct tree-iterator, but I can't see of an elegant way to introduce that in an imperative language while keeping the forking/recursion aspect clear

I would start with a tree primitive. That’s difficult enough, with variations on branching factor, whether the tree is self-balancing, whether it is immutable, etc)

I guess/expect that will have to expose the implementation detail of the branching factor (yes, a binary tree is a special-case of a https://en.wikipedia.org/wiki/B-tree for B = 2, but algorithms tend to be different)

On top of that, build a library of tree traversal routines (breadth first, depth first with a few variants), allowing the user to specify code that decides, on each node visited, whether to navigate further down and whether to stop the traversal.

Now, whether the language proper needs a generic way to specify tree traversals? I doubt it, and doubt even more that it is possible too that in a way so that a) most graph traversal algorithms can use the primitive and b) the result is easier to use/looks significantly nicer than just calling those routines.

For perspective, I'm a novice with algorithm design, I've been grinding leetcode for the past 6 months or so, almost exclusively in Rust. I was bewildered by the same concern since I had initially set out to, not only focus on Rust, but to primarily maximize use of the Iterator construct, since I was not intricately familiar with it. A few months in I discovered that there was an appropriate Iterator construct which accomplishes the same thing.

  // Comments for the non-Rust native reader, regarding this Function declaration:
  // successors is a function that accepts an `Option` container for some Value of type T, called `first`
  // and a Closure called `succ`, constrained below:
  pub fn successors<T, F>(first: Option<T>, succ: F) -> Successors<T, F> ⓘ
  where
  // `succ` must receive the iterated state, and return the next iterated state
    F: FnMut(&T) -> Option<T>,

  // Each time the `next()` function is called on the returned Iterator (a Successors-flavored iterator),
  // the state of `first` is yielded, and then
  // `succ` is called to progress
  // until a `None` type is reported by `succ`

I'm not sure where the concept came from, but it's not dissimilar to the author's implementation, but instead of the ControlFlow enum, it relies simply on the Option enum. I know though, that it was initially built in the Itertools crate as unfold and then upstreamed some time later.

Essentially you use `first` to contain a Queue, Stack, or Level for the different traversals, and define traversal or activities from there.

It's fairly ergonomic in practice, ergonomic enough for Leetcode.

Here's a BFS: https://leetcode.com/problems/course-schedule-iv/solutions/6...

[0] https://doc.rust-lang.org/std/iter/fn.successors.html

[1] https://docs.rs/itertools/latest/itertools/fn.unfold.html

I'm 100% sure smug Haskellers have something very important to say here. :)

Standard tree traversal loop (yes, missing some obvious conditionals I didn't feel like typing out):

    var todo = new List<T>();
    todo.append(root);
    while (var item = todo.pop_front()) {
      todo.append(item.left); // or .prepend for depth-first
      todo.append(item.right); // or .prepend()
      // do stuff...
    }

Couldn't you just do this with a regular for loop and a few datatypes/functions? (This pseudocode is an Elm/Haskell/Rust/TypeScript-inspired abomination, but pretty portable to any language...)

    type Node = { value: Any, left: Node, right: Node }
    type Direction = Left | Right
    type TreePosition = { root: Node, currentNode: Node = root, position: Direction[] = [] }

    # Implementation left as an exercise but should be obvious and run in O(1), I believe. Returns Nothing when we're out of nodes.
    function nextPosition(position: TreePosition): Option<TreePosition>

    # The tree you want to iterate through
    const myTree: Node = ...

    # The loop
    for(let position: TreePosition? = TreePosition(root: myTree); position != Nothing; position = nextPosition(position) {
        node = position!.currentNode
        # Your loop code
    }

I'd argue this doesn't belong as a language-level feature, but maybe an API/stdlib-level feature.

For what it's worth, the ParaSail parallel programming language (https://github.com/parasail-lang/parasail) supports this:

    func Search(Root : Tree; Desired_Value : Tree_Value)
      -> optional Tree_Id is   
        var Identifier : optional Tree_Id := null;
 
        for T => Root then Left(T) || Right(T)
          while T not null concurrent loop
 
           if Value(T) == Desired_Value then
              // Found desired node,
              // exit with its identifier
              exit loop with Identifier => Key(T);
           end if;
 
        end loop;
 
        return Identifier;
    end func Search;

I actually don't use this feature much, because usually there is a key of some sort that determines which side of the tree is of interest.

I think this kind of control mechanism is not a great idea and could lead to easy bugs.

I think it's a better idea to write a function that applies a function to the elements of a tree. Ideally you'd make a function for each traversal order. This makes it obvious what is happening.

map_tree_pre(my_tree, my_func);

map_tree_in(my_tree, my_func);

map_tree_post(my_tree, my_func);

map_tree_bfs(my_tree, my_func);

Or maybe you need a different language, where implementing an efficient tree traversal operation is easier?

One thing I wish for is for standard library trees to present a way to take advantage of a trees structure, even if they don't directly expose the tree itself. For instance, C++ map could expose a way to start find or e.g., lower_bound from some node. While I'm making a wishlist, I also wish lower_bound worked with reverse iterators (see e g., https://stackoverflow.com/questions/64351187/stdlower-bound-...) :)

I think allowing for starting this kind of search from a given node would cover most (though not all) of what you'd want to expose the trees structure for directly.

Branching iteration seems like a great idea. But I think the syntax shouldn't come from tree traversal. It should be something general. You tell the normal for loop how to go to the next sibling (`increment`) and when to end naturally (`condition`) or prematurely (`break`) and how to skip current sibling (in whole or partially) (`continue`). Branching iteration would also need to know how and when to branch, that includes skipping branching for this particular item, end whole iteration naturally and prematurely.

So something similar to `break` and `continue` should be the method of branching (descending into the tree).

I think Scala might be a great language to prototype implementation of such construct.

Adaptive Programming[1] by Karl Lieberherr is the most comprehensive attempt I have seen to formalize and separate iteration over arbitrary structures as a distinct PL construct.

It allows you to specify traversal in a structure-shy way. Personally, I think it goes a little too far, but it's definitely a good inspiration.

[1] https://www2.ccs.neu.edu/research/demeter/

Presentation: https://www2.ccs.neu.edu/research/demeter/talks/overview/qua...

What is this note before the code about?

> This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.

Also I’m slightly confused by this example.

    for_tree(string x = ""; x.size() <= 8; x : {x+"a", x+"b", x+"c"}){
 print(x);

}

So, our “next node” operation is to concatenate to x. Won’t we either have to have a method for modifying x to go “up” a node, or we’ll have to keep a record of what x was upon entering each node? Like in this example we’ll end up with x=“aaaaaaaa” and then go up a node, over to a “b” node, and get x=“aaaaaaaab”, right?

I would think iterators are exactly this. And they exist in almost every language.

I've written about this before, but suggesting recursion for tree traversal is equivalent to suggesting goto is a replacement for if/for/while.

We don't have syntax and semantics for recursion schemes in any programming language - it's always deferred to library support at best. As far as I'm concerned, this is an open problem in programing language design where we finally replace the vestigial recursion hack with a proper structured programming solution.

This implementation recurses on the call stack and calls that out as a feature. A built into the language tree walk which overflows the stack on large trees is perfect for C++, get a paper over to WG21.

Or for a possibly more useful comment, constant space tree traversal is genuinely quite difficult to implement. I don't know a general solution to it (other than walk from the start N times, quadratic style), would be interested to hear of one.

Sean Parent developed ‘forest’ for C++ that automatically maintains the invariant that its structure is always a hierarchy. It includes full-order iteration through its default iterator: https://stlab.cc/2020/12/01/forest-introduction.html

This is heavy biased to C++, which is a language that already has too many features that people just want to use. This is a very specific case to be placed as a language feature, and could be just a lib.

If this becomes a C++ feature, imagine how many data structures we would need to support?

Many other languages, specially the FP languages, allow to do that as a library. Even the languages that are only inspired by FP. Example, Ruby:

  class BinTree
    include Enumerable
  
    def initialize v, l, r
      @v, @l, @r = v, l, r
    end
  
    def each &block
      @l.each(&block) unless @l.nil?
      yield @v
      @r.each(&block) unless @r.nil? 
    end
  end

Using the Enumerable mixin includes many FP-based methods, such as map, filter and reduce by only defining each, which in this case is DFS.

Then we can proceed to define a binary tree:

  tree = BinTree.new(
    1,
    BinTree.new(
      2,
      BinTree.new(4, nil, nil),
      BinTree.new(5, nil, nil)
    ),
    BinTree.new(
      3,
      BinTree.new(6, nil, nil),
      BinTree.new(7, nil, nil),
    )                 
  )

Iterate over all the elements:

  tree.each{|v| puts v}

Iterate over the even elements:

  tree.filter{|v| v.even?}.each{|v| puts v}

Stop iteration when finding a value:

  tree.each do |v|
    break if v == 1
    puts v
  end

And so on. The same can be done in Python, Kotlin and many others.

I worked for Guidance Software in the aughts and their main product, EnCase, had its own proprietary scripting language built in, called EnScript. Everything in EnCase inherited from “NodeClass”, a linked list for creating trees.

EnScript had a forall(NodeClass n in tree.GetRoot(){} construct that was very easy. It was essentially a depth-first iterator.

For isn't "linear traversal", it's linear execution. It's up to the data structure to define what linear traversal is. For arrays and lists that's trivial. For trees and, more generally, graphs there are many ways to do traversal. This is what iterators are for.

well, functional languages with recursive types, are very good at representing binary trees

https://cs3110.github.io/textbook/chapters/data/trees.html

sticking to dfs, there is still a difference between pre-order/in-order/post-order

It's not at the language level, but for python JAX has the notion of a pytree (arbitrarily nested combination of lists, dicts, and tuples), and includes map and reduce operations for those objects. It's very convenient!

How in the world is this getting a HN hug of death when it's a substack page?

Well common lisp has it.

What you want is 'yield' and generator coroutines. We have them in C++20, but their codegen is very poor compared to a manual implementation.

What programming languages need is dimensional analysis. The fact that I can make variables like

Const km = 1 Const velocity = 11

And do km + velocity = 12 is all kinds of silly.

Here you go!

A TXR Lisp macro for-tree for traversing a tree, given a variable, an expression for the root node, and expressions for how to to left and right relative to the variable.

A node structure that for-tree knows nothing about. No iterator abstraction or API, nothing.

  (defstruct node ()
    value
    left
    right)

Example tree (a balanced binary tree whose numeric values happen to be sorted):

  (defvar example-tree #S(node value 5
                               left #S(node value 3
                                            left #S(node value 1)
                                            right #S(node value 4))
                               right #S(node value 7
                                             left #S(node value 6)
                                             right #S(node value 9)))

Walk it:

  (for-tree nod example-tree nod.left nod.right
    (prinl nod.value))

  1
  3
  4
  5
  6
  7
  9

Code:

  (defmacro go-leftmost (var root left-expr stack)
    ^(for ((,var ,root)) (,var) ((set ,var ,left-expr))
       (push ,var ,stack)))

  (defmacro for-tree (var root left-expr right-expr . body)
    (with-gensyms (stack node left right)
      ^(let (,stack)
         (go-leftmost ,var ,root ,left-expr ,stack)
         (for ((,var (pop ,stack)))
              (,var)
              ((iflet ((,right ,right-expr))
                 (go-leftmost ,var ,right ,left-expr ,stack))
               (set ,var (pop ,stack)))
           ,*body))))

The left-expr and right-expr must be expressions that involve the var variable; the construct evaluates these to find the left or right child. When the value is nil it means there is no child.

This is almost exactly what the blog is asking for, transliterated to Lisp syntax.

Original concept in fantasy C syntax:

  for_tree(Node* N = mytreeroot; N != NULL; N : {N->left, N->right}
  {
    print(N->value);
  }

Lispified:

  (for-tree nod example-tree nod.left nod.right
    (prinl nod.value))

As required, the construct specifies the node variable to be the loop dummy, the root expression giving its initial value and the two accessor expressions for left and right traversal.

The termination test N != NULL is made implicit in the Lisp version, so early termination requires a break out of the loop. It could be arranged.

The fantasy C syntax specifies a variable name in the navigation declarator: N : { N->left, N->right }. Presumably, the variable here can be renamed to anything you want; it just arbitrarily happens to have the same name as the loop dummy.

I didn't replicate this feature exactly because it just adds verbosity for nothing. It's okay if the navigation declarator just refers to the loop's one and only dummy variable.

Anyway, programming languages should definitely not have a tree traversal primitive. Rather, languages should be Lisp.

  1> (for-tree n (tree-root #T(() 1 2 3 4 5 6 7 8)) (left n) (right n)
       (prinl (key n)))
  1
  2
  3
  4
  5
  6
  7
  8
  

  2> (for-tree n 1 (if (< n 8) (* 2 n)) (if (< n 8) (+ 1 (* 2 n)))
       (prinl n))
  8
  4
  9
  2
  10
  5
  11
  1
  12
  6
  13
  3
  14
  7
  15
  nil

  3> (for-tree n 1 (if (< n 8) (* 2 n)) (if (< n 8) (+ 1 (* 2 n)))
       (format t "~b\n" n))
  1000
  100
  1001
  10
  1010
  101
  1011
  1
  1100
  110
  1101
  11
  1110
  111
  1111
  nil

  2> (for-tree n 1 (if (< n 8) (* 2 n)) (if (< n 8) (+ 1 (* 2 n)))
       (format t "~6b\n" n))
    1000
     100
    1001
      10
    1010
     101
    1011
       1
    1100
     110
    1101
      11
    1110
     111
    1111
  nil

  3> for-tree n 1 (if (n < 8) (n << 1)) (if (n < 8) (n << 1 | 1))
       (format t "~b\n" n)
   1000
   100
   1001
   10
   [...]

programming languages shouldn't have such primitives, because they're not primitive. Otherwise, people programming different stuff all the time, would need other primitives, and you'd have unmaintainable languages full of bugs.

Of course not. You already have iterators.

Haskell (for example) doesn't even have a looping primitive. Why would it have a tree traversal primitive?

Both looping and tree traversal can be done with library functions.

In general, everything that can be done with library functions, should be done with library functions.

> Doesn't for_tree(...) look a lot nicer and simpler and less error prone than needing to implement a recursive function for each operation you would want to do on a tree?

Eh, in Haskell you can derive many of these things automatically. And even Rust has some automatic derivation.

FWIW, I use Null Objects to eliminate null checks. Makes recursion (tree climbing) more concise, legible.

Bonus: Java's HotSpot magick will NOP (most?) methods of Null Objects, making this a zero cost abstraction.

I should probably write a concrete example for a blog or something.

TLDR: For every base class such as TreeNode, create a NullTreeNode that does nothing, then replace all uses of null with NullTreeNode. Voilá, no more null checks or NPEs.

It's called sum types and pattern matching, and this is like 80% of the reason why I like Swift and Rust.

Its called recursion

> Doesn't for_tree(...) look a lot nicer and simpler and less error prone than needing to implement a recursive function for each operation you would want to do on a tree?

No it does not

Operating systems have this with file systems.

Web browsers have this. It’s the DOM and it scares the shit out of most JavaScript developers. The fun part is confronting people about their irrational fears watching them spin their wheels with all the imagined excuses.

I am a tremendous fan of tree systems. Tree systems should completely replace inheritance in programming to enforce the composition over inheritance principle.

Ordering pizza is much more important and frequent part of a developer's work than tree traversal. Therefore, programming languages need pizza ordering primitive even more, than tree traversal ones.

Nonsense.

Programming languages should have less primitives like this and instead we should have better foundation libraries for the languages, i.e., containing iterator/-interfaces like Rust and Python (or Smalltalk).

My concern here is what a recursive primitive like this in a low level language (like C/C++/Zig/Rust) would imply to the execution context of the "code within the brackets". If it was within the context of a lambda, etc that's one thing.

I will be transparent here, I do not know of a non recursive, tree traversal alogorthim that uses constant storage but doesn't modify the tree.. (Morris Traversal satisfies 2 but makes temporary changes to the tree)

Most primatives do not allocate hidden data (even C++ iterators require you to instantiate the iteration state as a variable) and operate within a known stack/execution context.

Having an actual primitive that implements arbitrary tree traversal would require a substantial complier generated, but non-transparent, framework for that execution. It would either need to be recursive, have localized dynamic data, or would require tree structures that are well defined to use something like Morris. (And Morris is natively non-concurrent even for reads)

While this means that that simple primitive would actually do a lot of potentially problematic things under the hood. How many Junior programmers would call it concurrently for reads because it's not "modifying the data". Why do you need to lock? Things like brake and continue and other control mechanisms wouldn't actually work as assumed from the flat context.... I.E what happens if somebody called a goto inside of that block? Also, in an embedded context where you may not have a dynamic allocator, how would a version written as in reiterative function with a expanding stack data structure function? From a language standard point of view, there are so many complexities to building something like this that runs in any context that the language is supported. Something like this that runs in any context that the language is supported.

I mean look at C++, they have specifically and (deliberately / arguably rightfully) failed to build copy on write strings (a simpler abstraction) because there are cases where they couldn't guarantee that they would have the expected results in all contexts.

This to me sounds more like something that should be a lambda function and a standard library, not a primitive... Languages that support dictionaries and maps as part of their standard data structures already have library support for tree traversal internally. They have solved many of the problems of making that language exposed, so that would be a much smaller ask. And programmers rightfully assume a lot more complexity within library calls then they do within primitives. Primitives are designed to be primitive. Having primitives able to create stack frames, dynamically allocate hidden memory, and/or recurse honestly worries me.

[dead]

[dead]

Horrible idea.

1. BFS is not supported.

2. Traversal type (inorder, preorer, postorder, or even mixed order!) is also not handled.

3. The syntax doesn't make it apparent that stack overflow can occur, e.g. by doing DFS on a linked list.

As a fullstack web engineer I've never had to implement a tree structure at work. I'd love to hear examples of what kinds of companies/platforms people are writing these structures regularly. If anyone is willing to share where they use them I'd appreciate it