New Tree Library

Can you provide a more detailed list of the 'functional limitations' you see with the current 'struct::tree' ?

And show how they are solved by your package ?

It is a bit difficult for me to read both sets of documentation and compare the two, with all the
different method names ...

Specifically, node names must be unique within the scope of the entire tree, so it is very difficlut to write code such as

set L [child [child $Tree left] left]

since there can not be two nodes named "left"

In my tree, node names are stored with a node, so you can have as many "left" nodes as you need. In fact, you could have two "left" children if you wanted. This was done to support XML stuctures like

  <someNode>
     <data>one</data>
     <data>two</data>
  </someNode>

In this example, "someNode" would have two children named "data".

All of the struct::tree methods require that the "tree" be specified. This means that "nodes" of a tree can not be treated as trees unto themselves, which defeats the computing definition of a tree.

Since struct::tree requires that a tree be specified, in order to write the same code as

  set L [child [child $Tree left] left]

you would have to write a routine to "pick" a child

proc pick {tree node child} {
  retrieve all children of node
  loop through to find one by name of child
  return this node
}

then go on to write

  set L [pick $Tree [pick $Tree $node left] left]

which is much more difficult to read and thus write without error. It is just so much cleaner in my tree.

With the struct::tree library, one can not prune off a tree, or node without destroying it. This is why the "move" routine is necessary, however, it is only possible to move a node within the same tree. It is not possible to break down one tree, while building it into another without copying (creating) the data in the new tree, and deleting it from the old tree.

With struct::tree you create a tree, and then you insert nodes. There is not method to create nodes, and you can not insert trees. When inserting nodes (which is the way you create them) you can give them a name, but you can not reference them by name when "picking" them as children. To keep track of this, you must asing a different name to the node. All operations are done as nodes, rather than trees.

Another example is that the "walk" routine would have to be rewritten to provide formatted output similar to XML. This is because to provide XML style format, you must simultaneously perform prefix, infix AND postfix traversals, and the struct::tree will only allow you to do one of them.

My tree library provides a walk that can handle all traversals at the same time.

In addition, it runs about 2x as fast. All written in pure TCL.

Basically, when coding with Struct::tree, one has to keep track of indexes of children rather than names. Conceptual names such as left and right can not be used because names must be unique within a tree. Because of this, the code is harder to read, and thus harder to write.

I hate being so critical of someone elses work, but I found it very difficult to use the struct::tree library. Conceptually, the struct::tree library does not treat nodes as trees, which by computing definitions is the very nature of trees.

Is anything further happening about this?

If you have the time, convert you code into a module suitable for inclusion into tcllib and then it can either replace or be available as an alternative tree implementation. If you provide a ready package plus a set of tests then it is easy to incorporate and maintain the new code.

Faster sounds good. Recursiveness is good too.

I believe that the tree package at the URL is ready for inclusion into the tcllib package. The downloadable tar.gz file contains the html documentation, a test script, and the library.

There might be some desire by the tcllib team to change the name of the package or the layout of the documentation, and I would be willing to assist in this process.

The inclusion of this package into tcllib has been proposed in Feature Request #459571

Seems like it would be best to submit a Feature request for this in the tcllib sf.net project.