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
