From: Sunil M. <sun...@ev...> - 2001-01-11 18:56:07
|
Marco Antoniotti wrote: > Hi Sunil, > > let me forward this to clocc-devel too. It is too interesting. I had meant to send my message to the list... So it is good that you have forwarded it :-) >> OK, let me ask some more specific questions on where you want to go with >> dependency handling. >> >> 1. Do you want to keep all the current component types-- :module, >> :subsystem, etc.? My impression is that you might not be interested in >> keeping all these distinctions, so I won't say very much about them. > > > I think we want to maintain > > :system > > :module > > :file > :private-file > > I do not believe people use anything different. Maybe :subsystem can > be maintained as well. The hierarchy displayed in the spec document > is just a start. > > What is the reason to maintain these three "roots"? I want to > understand the problem as follows. > > :system components have two characteristics > > 1 - they are mostly standalone (inasmuch as they do not depend > on other systems). They may be compared to "applications" > (and in this sense maybe it would be better to distinguish > systems into two kinds). > > 2 - they are "closed" (or "sealed") in the sense that they can > be accessed only via a well defined "published" interface > (in a sense the only thing that systems could make available as > a piece of testable information is their "version"). > > From this it follows that none of a system innards > (i.e. modules and files) is "visible" from the outside. > In this sense a "system" is a C/C++ "library". It also > implies that a system may depend only on the systems it > declared to depend on in its definition form. > > :module components are not standalone. > > They may depend on other parts of the system definition. > Other components can depend on modules as a whole, but not on their > "inner" definitions. However, each piece of a module may depend on > other parts of the system definition, barring the previous limitation. > One such dependency will make the whole module depend on it, although > this the actual "operation" order may not strictly follow the > module-assumed dependency. > > :file components are the building block of systems. > (apart from the :private-file definition) their dependency > rules simply follow from the previous definitions. Well enough... This to me is an issue of program complexity vs semantic expressibility. I was willing to trade off expressibility for a simpler solution in this instance. >> 2. Do you want to use topological sort to turn the list of components >> into a serial dependency, as you have called it? Or do you want to use >> topological sort to track inter-file dependencies and come up with a >> minimal set of operations? > > > Doesn't (1) imply (2) to a certain extent? I want the topological > sort to alleviate the burden to specify the exact "global" order of > "operation"s. As such (1) is good and (2) is good too. Well, there are two things that I can see happening with a topological sort. Suppose you have three components, C1, C2 and C3, defined in that order in your system. You declare a dependency from C3 to C1 and C2. A topological sort can then return with two valid orderings: C1, C2, C3 or C2, C1, C3. Now suppose you modify C1 and recompile your system. If you use topsort to get a serial ordering, then the implication (in my mind) is that for order 123 you will compile all three (as the topsort has produced that serial dependency), and for order 213 you will compile only C1 and C3. As C2 precedes C1, it can be safely ignored. If on the other hand you decide you want to do the right thing and decide to track the entire dependency graph, then no matter what serial order topsort comes up with you will always track the minimal recompilation. Tracking dependencies accurately is considerably harder to implement, but it is definitely the way to go to get the full benefit of topsort. >> 3. Do you wish to apply topological sort to components, between system >> dependencies, or both? I'm assuming both, in which case I shall try to >> change your mind :-) > > > I want to apply the topsort to components. The dependencies among > systems are of a different nature. I do not have a clear idea about > what to do when a dependency from system A to system B is in place. > > Setting aside the issue of "system versions", you can still ask the > question? > > Suppose I am manipulating two systems A and B (it happens to me: I use the > priority queue package as a building block in my application) with > system A depending on system B. I also have the dependency rule in > the definition of system A (note that IMHO this ruls is not quite > well addressed in MK-DEFSYSTEM 3.2i). Now, I find a bug in system B > and fix it. However, I recompile/reload system A instead of > recompiling/reloading system B. What should happen? > One way to resolve the dependency (i.e. to propagate the operation to > system B) could be to keep a "system wide" modified-flag in the system > definition which could be tested in this case. > > This is just a thought. I already have put in a DFS based approach for handling system dependencies correctly. Each system tracks its load time, compile time and definition time. This allows the minimal set of systems to be determined for a requested operation. Since you want to apply topsort only to components, there is little else to add :-) >> There is a very natural place where topological sort can be introduced >> into the current order of events. A gf, operate-on-next-component, walks >> through the components list of a system. Components may be arbitrarily >> ordered at this stage, which is what you would want to do for a >> topological sort. If all you are interested in is turning a list of >> dependencies into a nicer serial ordering, that would be trivial to >> accomplish. (AFAIK, that is what CLOS does as it dynamically calculates >> the specificity of methods for some set of arguments.) The more complex >> operation of calculating a minimal set I believe could also be done in >> the existing framework. But that might take a little more creative >> work. > > > I am assuming, one component = one operation. If you can serialize > the components, why bother with "minimality" of operations? Perhaps I have made some assumptions about what you saw as defsystem's functionality that are muddying the conversation... Refer back to the example I gave regarding the ordering of the three components. The minimal set of operations there is on the components C1 and C3, while a serial dependency in the worst case would recompile the entire system. Finding the minimal set is to me obviously desirable, but considerably more difficult to implement. Sunil |