It just struck me that I went thru the entire meeting thinking that the assumption was that we were trying to launch an open source effort to support open source.
I now realize that some there were not making that assumption.
I think we need compatible short and long range visions.
We don’t necessarily need to draw a complete picture of steps to the ultimate goal.
Indeed we must expect the long range goal to shift as we approach it.
Indeed contrasting long range visions might serve better and attract more contributors.
This does have the makings of a Dilbert cartoon., so let me get way down into details of desiderata.
- Remote read-write access to a tree structure of information.
Some consideration of access control is needed.
I have not seen an entirely adequate solution of even this much of the problem.
I suspect that we must proceed without one.
- I think that Don Knuth’s web ideas that connect code together with commentary is good.
The details of Knuth’s “Literate Programming” seems too devoted to paper publishing.
Interactive reading and view control (ala Augment) is easier and harder than paper publishing.
We shall also need to countenance legacy code.
- Preprocessors: UGH!
You want to see the source but preprocessors may, and often do, transform from a form of language that language savvy tools cannot navigate.
One approach to this is in some development environments the editor can immediately show you the yield of the preprocessor.
This is generally not possible for systems predicated on the Unix tool called “make”.
- In light of the above dilemma I would dearly love to have the machine show me the declaration of a particular identifier that I point to, even if preprocessing has produced the declaration.
- I want to collapse and expand the representation of the code according to the code’s tree structure, again ala Augment.
- There is a solution to all of this.
It requires inserting code between “make” and the compilation process.
This code, called the intervenor here, captures the official post-pre-process compiler input and allows language savvy navigators and inspectors to work in the language that they were designed for.
Extra tools, called the back-map, integrated with the intervenor help work back to the real source.
The back-map does its thing by introspectively performing the preprocess thing leaving behind a trail of crumbs that amount to pointers leading back to the real source so as to explain what in the real source (and include files) caused the artifact (such as a declaration) in the real C code where the navigator found the official declaration of some identifier.
- Many would say that such stuff is for sissies, but they have probably not had to delve into massive unfamiliar code.