It's been a pretty long time since the last Cells release, and in particular, what asdf-install gets you is the old Cells-I codebase. So, Kenny, do you have any problems with labeling the current cvs as Cells 2.0? In case anyone is wondering, "why now?" or "why not months ago?": for the second question, I massively overcommitted myself at the end of last year between OSS projects, finishing up contracts, and moving to Germany. Guess which lost out? :-) For the first question, a major motivating factor is Munich. The brand-new Munich Lispniks group looks to be fertile ground for evangalization, provided that what I'm evangelizing is asdf-installable and not just in CVS. In particular we have Alex Burger ("The PicoLisp Guy") and Peter Hearth ("The LTK Guy"), among others.
So, if anyone has any objections to a Cells-2.0 release sometime in the next few weeks, raise them now.
This brings me to my next point: whence Celtic, and whither? At my new job, I can talk to Peter Hearth without getting up from my seat, so I've started using LTK a bit, and we'll probably be standardizing on it at work. His motivation with LTK was not just to produce what exists now, but to use it as a base for a good, capable library of sophisticated widgets built in Lisp. For that layer, he's receptive, at least in principle, to a Cells dependancy, especially if it makes things easier. I'm far form having convinced him of that, but he's interested in seeing something I do using Cells and LTK. This coincides quite nicely with my extreme desire to *use* Cells whenever I touch LTK. I write code in a fairly functional style, and for stateful GUIs, you almost can't do that without a constraints system. At least, I have a hard time doing so -- hell, I've already hacked up 1/4 of a Cells/KR competitor just in the process of trying to write a GUI app.
The only thing that I've seen that stands in the way of Just Using Cells with LTK is that LTK creates the TK objects too eagerly: in TK, objects have a certain "path" (parent/child relationship), and this is being set before Cells would have a chance to initialize the dataflow system, which in turn would determine *where* some objects should go in the parent/child path. LTK used to work differently here, in a way that would be Cells-compatible, and Peter has agreed to change this (or to accept a patch from me changing it ;). So, whence Celtic, why the fork from LTK? We worked out the proper time to do this, that lets all coding styles we could think of work. Once that's in place, using Cells in an LTK app, or for the MegaWidgets library Peter is building on top of LTK, is a simple matter of using defmodel for the classes you define. Bada-bing, bada-boom, c-formula anywhere you want.
Given all of this, whither Celtic? At most, it looks like it should just be a MegaWidgets competitor, built on top of Peter's LTK codebase, since that *will* see commercial support. But in that case, assuming I convince Peter of constraints systems, why not just merge with MW? In the worst case, if Peter sticks with The Imperative "Way", and Celtic remains, built on its forked base, I'm going to have to build myself an aggregadgets library to keep my sanity, which means *three* ostensibly competing systems. Yuck.
Reasoning dialectically, does Celtic even have a future? I'm guessing its fork was somehow motivated by the specific desire to use it for a software product; that product probably isn't happening, right? In that case, this sounds like the kind of internal contradiction that should be fatal. With the integration of Cells in LTK, Celtic will have finished its historically progressive role, and will continue to exist only to haunt the Lisp world as a spectre of raction, a vertiable Cossack of Common Lisp. Against the philistines! For the ejection of Celtic from cell-cultures, which should aspire to be the Paris Commune, the Jacobin Dictatorship, the Radical Reconstruction, the October of Common Lisp, not the Bismarkian Prussia or Russian Don!
Okay, less Lenin next week, more Lattice Theory.
-Thomas