John Lunzer's recent remarks has triggered one of the biggest Aha's in Leo's history, one that was totally unexpected until this afternoon.
Leo's fundamental data structure is a tree of nodes. More accurately, it is a Directed Acyclic Graph or dag. Links in such a graph can point "down" the tree, but never up, so there are no cycles. Leo's clones are well defined just exactly because there are no cycles. Given a node, we know precisely *and* intuitively which nodes are descendants. Because of clones, a node may have more than one parent. Here's the Aha. Imagine this data structure as being linked with *black* thread. Now imagine another *completely independent* set of *red* threads. The only requirement is that the links defined by the red threads must *also* be a tree/dag. That is, there is *absolutely no* necessary relationship between the red and black threads. Now imagine that every Leo attribute creates its *own* sets of links/threads. *We have a new view for every attribute.* Let's call such a data structure a *multi-threaded tree/dag*. Trees might actually be enough, but I'm not sure so I'll refer to tree/dag (tree or dag). *Important*: some nodes may not have any thread running them for some colored threads (attributes). That's just fine. Alas, the term "multi-threaded data structure" is commonly used for data structures that can be accessed by independently running threads. That's not at all what I am talking about. I am not aware of anything like this in graph theory. Could this be a truly new idea? I really have no idea. Of course, you could call the resulting structure a general graph, and technically it is, but how the data structure will be used inside Leo is *very *different. Instead of a single, unintuitive mess, we have a collection of easily traversed trees/dags. *We instantly have an arbitrary dimensioned graph*! Each color creates a new dimension. Of course, we only *see* one dimension at a time, but attributes may be the *composition* of other attributes (unions, intersections or other relations), so this is no real restriction. And listen to this. *It is astoundingly easy to create this multi-dag in Leo*. At present, each vnode has a parents list and a children list. All we have to do is replace these two lists by dictionaries whose keys are attributes and whose values are the parents or children lists for those attributes. Finally, we add Python properties shield the dictionary lookup from the rest of Leo. We are talking about maybe 50 lines of code! As far as the rest of Leo is concerned, vnodes *still* have parents and children lists. The switcheroo happens totally invisibly, when the user wants to see another view. The attribute changes and that changes what the vnode dictionary/properties "deliver" to the rest of Leo. To recap: What we see depends only on the attribute that defines the view. This attribute determines what parents and children lists become active. So easy. So very powerful. Each *current view* will show only the nodes with the given attribute. To repeat, attributes can be composed of other attributes, so in effect each view can be associated with an *arbitrary set* of attributes. This is an *astoundingly* general data structure. The real challenge lies in assigning different colored links to nodes. I'm still trying to wrap my thoughts around all of this. As always with truly huge Ahas, it's already impossible to know exactly what thoughts lead to it. As soon as the Aha happened, the world changed so much that the past becomes hard to reconstruct. But for sure the following factors were "in the air": 1. Most importantly, the consensus has been building among the usual suspects that attributes are a more intuitive, and perhaps more powerful, alternative to clones. 2. For the last year I have been trying to ignore the fact that sometimes clones get in the way. This was the meaning of today's remark that "I love clones, I hate clones". 3. John's remark about attributes and hoists certainly triggered the avalanche. *Notice*: multi-threaded tree/dags collapse a lot of behind-the scenes complexity. In particular, both hoists and chapters are a (mildly successful) attempt to make clones do the work of attribute-based views. In the new scheme, we simply re-thread nodes that we want to be part of the new view. *And notice*: when we require that views be made of clones we can *not* change any parent/child relationships. But that constraint completely disappears when we use attributes to define views. *Summary* This is one of the most momentous Aha's in Leo's history. It was completely unexpected this morning. It is almost too easy to make it happen. I may do it this evening. There remain important user interface questions concerning how nodes get assigned various colored threads, but I have faith that the result will be truly amazing. This Aha will have a huge number of happy consequences. Just for starters: 1. Searches can be limited to a single view (thread color). If we don't use clones in a view, each search will find a node at most once. This will erase my biggest pet peeve about Leo! 2. Every view (attribute) can define/create its own set of parent/child relationships, independently of all other views. Afaik, no other data structure is this flexible while still remaining intuitive. 3. It will be *very easy* for attribute editors to show nodes having those attributes in the most natural way *for that attribute* without being constrained in any way by other organizations of the data. Yes, this is really just a restatement of 2, but it's different in practice. No way would this Aha have happened without the interesting conversations that have taken place in the last few months. Well done, all of us! Edward -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
