I'm trying to see the use case. I know you use clones to gather scattered bits which are relevant to an issue. I'm seeing this 'colored threads' concept applying like this:
The 'black' thread has nodes arranged in code-correct order, as they would need to be presented to the interpreter. The 'red' thread is the arrangement which I currently see in the body pane, with the currently interesting nodes isolated for convenience. The structure of the .leo file is more arbitrary than before, since node attributes define multiple arrangements, though I suppose there would be a default, 'black' in this case. Maybe 'green' would display as the documentation, with code and narrative interspersed. Am I on the right track? Thanks, Kent On Thu, Feb 11, 2016 at 5:12 PM, Edward K. Ream <[email protected]> wrote: > 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. -- 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.
