On Monday 03 October 2005 16:23, Thomas F. Burdick wrote:
> >From the hyperspec: > "The :initform slot option is used to provide a default initial value form to > be used in the initialization of the slot. This form is evaluated every time > it is used to initialize the slot." -- see, it says "every time it is used to > initialize the slot" not "every time the slot is accessed."
I think what you're missing is that c-formula does not return a function, and c-input does not return its argument. They return cells, that's the main thing.
As a secondary point, MODEL-CLASS is[*] a metaclass, which provides for special semantics for CELL-SLOTs. In general, most slots in MODEL-OBJECTs are CELL-SLOTs, but you can request a STANDARD-SLOT by specifying :CELL NIL. The cell that computes the value for a CELL-SLOT (either an input cell or a cell formula) can be provided by an initform, or by an initarg; or even later, by replacing it after TO-BE-time (but this is not recommended and I don't think covered by the test suite, so it could be broken atm as well). So, STANDARD-SLOTs have values, CELL-SLOTs compute their values.
[*] (Bill Clinton-style, I am in fact footnoting "is".) This is the model, anyhow. If the MOP were portable and portably efficient, it would be the implementation as well. As a "mere" portability and performance hack, this isn't how it's implemented, but it should be how you think about Cells.
Thanks. You are correct that I was not of that mindset -- thinking of c-formula and c-input as evaluating to cells. I'll still have problems though because (1) as you point out, defmodel creates standard-class, also (2) cell slots are standard-[direct/effective]-slot-definition -- there is no cell-slot from what I can see, (3) I really don't know what a cell is.
I've tried to define a taxonomy of cell in the cells-gtk documentation, but I'm really guessing. If I had that much, I think I could probably fill in some of the holes in the documentation.
Looking at the standard-class instance created by defmodel, I see what looks pretty much like a standard-class with standard slots. But it doesn't act like one. So an introspective program is as likely to be as confused from its viewpoint as I am from mine.
That said, I've written a fair amount of MOP code and wouldn't be critical of anyone taking a different route for reasons of portability.
> I'd call the role :formula or even better :derived-by, not :initformula, but > what's in a name? (provided that name doesn't already associate with a > meaning, as does :initform).
Maybe it's really that you don't like the decision to make :CELL T the default and thus implicit in using DEFMODEL?
> > i think the problem of the initform not actually becoming the slot value > > is a problem only for those who have never seen Cells before and have > > not had the briefest introduction. So I say leave it as it is an explain > > it. :):) > > Sure, it can be learned. Like GTK itself, I have just enough knowledge of > Cells to be dangerous. My concern is getting cells-gtk users up to speed as > quickly as possible. Definitions of the concepts used, and predictable > semantics of the language are the what makes our work effective (and why we > like lisp -- compare with Perl or Python, where the semantics change often, > and are ill-defined).
I've seen Cells' semantics change over time, but in the direction of more well-defined. They also stand in the long history of simple Knowledge Representation systems in Lisp. Admittedly, that's the family of OO systems that were neglected by the ANSI standard, but if you're familiar with CLOS and any of the other simple Constraints/OO systems in CL's history, the semantics of Cells are pretty obvious -- and actually, *really* erring on the CLOS side of things.
Yeah, I've used a few. Screamer, etc... While working for an apparel CAD company I wrote (in lisp) a constraint-based system to design the various sizes of a garment, given a base pattern.
Its not the concept that bothers me. Nor even the execution of it. Its just that every time I come back to my cells code, I've forgotten a few things about how it works, and I don't have enough notes to fall back on. And I suppose potential users of cells-gtk are put-off by the lack of guidance...maybe not ...I do it...who knows.
> But of course there are only so many hours in the day, and so much to do. So > nothing is ever going to be perfect.
You might also want to look at the documentation for Garnet and KR. One of the great things coming out of that research was a fantastic manual and some very readable papers. KR is a prototype-inheritance object system, and used lazy evaluation of rules (as oposed to Cells' being class-inheritance object system defaulting to eager evaluation); however, it provides examples of good style for using one-way constraints (what Kenny more descriptively calls a spreadsheet dataflow), and expecially in a GUI context. At the rate things are going, I won't have an alpha draft of the Cells manual until the end of 2006, and by that time Kenny will have produced some more good use-cases, but no manual -- so if you'd like a users' manual type of thing, I'd recommend crossing the Garnet docs with what you know about CLOS and Cells.
In the meantime, I'm prioritizing Cells-LTk over Cells docs for my little free time, because the main thing is to get a Cells-controlled toolkit that gives me Pin-Striped Aqua :-):-)
We could do pin-striped aqua in Cells-gtk, if it would mean you'd help by using it, debugging it, or write the cells docs :^)
I'd be happy to read a draft of any Cells documentation you write.