On Sun, Apr 18, 2010 at 10:31 PM, Robert Goldman rpgoldman@sift.infowrote:
For what it's worth, I'm happy to see an agile development, but I would strongly discourage implementation as the main way of introducing new features.[...] Right now, the only way to get started working on ASDF is to read a great deal of code, and understand a number of subtleties and oddities about how ASDF functions now. If there was, for example, a clear description of the plan-generation function that is implemented in TRAVERSE, it would be a lot easier for someone to start working on it.
I am not going to attend the ILC because of personal and job constraints. Please understand that by "adding" I do not mean exclusively increasing functionality but limiting and making it more precise what is currently being done. That also means "specifying" precisely, in the manual or wherever it should be, what is going on.
Examples: * Policy when reading asd files * Policy on packages when reading symbols * Policy on the parsing and desconstruction of DEFSYSTEM form * Policy on the creation of CLOS objects and binding them together * Policy for declaring new options or fixing the existing set ...
Basically what I meant is: "let's discuss today the creation and specification of a function that parses DEFSYSTEM", somebody lists a sets of things it has to do and comes up with a simple function. We discuss whether it is ok or not, and in parallel it can be verified with the multi-implementation/multi-library test system -- another goal which should be attached to the ASDF project.
Then some of us takes the final formal specification and adds it to the documentation or saves in the launchpad for later edition.
So the emphasis is that every contribution should come with both a clear set of steps, a place to document it and a model implementation -- all of it being subject to inspection and scrutiny here at the list.
Juanjo