On 7/21/16 Jul 21 -5:47 PM, Andrew Sengul wrote:
Hi Fare, Robert and Dave,
Thanks for your suggestions, I read Drew's paper and his chunks system is close to the kind of thing I'm looking to implement. I also looked at cells, Garnet and Gendl. I downloaded Garnet and have been looking through the KR code; Robert, is there anything else you would suggest if I'm going to try using KR?
Not really. I only ever used it as part of the Garnet system. Garnet, FWIW, is really awesome but.... (1) it's bitrotted (especially its X interaction and its pre-ASDF build system); (2) learning curve; (3) stock look and feel is so nasty that you don't realize how awesome it is (when I was using it, I had the great good fortune of working with a human interface expert who told me how to fix the default color scheme, widget shapes, and font choices, but all that customization was lost in a proprietary corporate filesystem :-()
Are there any cells examples lying around? Recoding them might be reasonable. Or it should be trivial to find examples intended for a Truth Maintenance System and translate them into KR. Maybe something from Forbus & deKleer's "Building Problem Solvers" would be suitable.
I'm going to use ASDF as the basis for this project at least to start with. One of my goals is for the systems I'm building to be usable as portable software modules, so implementing them as ASDF packages is a natural choice. At least at the outset, I don't have a problem with ASDF's model being filesystem-based; it's fine for the components of each system to be defined in the form of files. I think requiring that a file be saved whenever a change is made to a component is inefficient, but that can be left for now. My eventual goal will probably be to combine a constraint-solving system with ASDF; perhaps chunks can be implemented as part of an ASDF extension. I've got the chunks code but it doesn't compile for me with SBCL, so more work will be needed on that front.
I tried for a while to get Drew's yale tools to compile, but I never was fully successful. On my "someday I'd like to do this" list is extracting some of that stuff and making it more compatible with ordinary lisp usage.
Any thoughts you have on this direction for the project are welcome. Thanks,
Sorry, I'm afraid those were not too helpful.
best, r
Andrew
On 07/19/2016 07:13 AM, Robert Goldman wrote:
Drew McDermott made a build system called (IIRC) "chunks," that did just what you want: it put dependencies on arbitrary data structures and recomputed them on need. One challenge is that his build system is built on top of his "yale-tools" mega-library, which can be difficult for outsiders....
Here's Drew's paper, A Framework for Maintaining the Coherence of a Running Lisp: http://www.cs.yale.edu/homes/dvm/papers/lisp05.pdf
I suggest you read this, and see if you could graft the ideas onto ASDF (with suggestions from asdf-devel).
ASDF mostly uses the filesystem to track dependencies (although it has an internal db, as well), so there would be a little effort to extend to a non-file-centric build.
Drew's key idea is that his system (and ASDF), unlike build systems like make or ant, have as a primary job maintaining the integrity of the running lisp image. [Faré may disagree with this claim: he comes to Lisp usage with a newer perspective than my old-school view.]
Drew's system is less fine-grained than the cells system that Faré suggests. I don't think the cells system ever got mature enough for use.
If you want a dependency-driven, lisp-based constraint system per Faré, I think you'd have better luck with the KR system developed a long time ago at CMU. It is primitive in some ways (hand-built on structures, rather than using CLOS), but was used for years in a very high-stress environment, so is much more likely to work than cells. KR is available as part of the Garnet UI system. Drop me a line if you are interested.
Best, r