Peter Denno writes:
On Sunday 02 October 2005 22:13, Kenny Tilton wrote:
I think the problem is that :initform is actually Deeply Correct. A form is being supplied for a slot. That form itself screams that it is a formula, so there is no ambiguity. You see confusion becuase the rule does not become the slot value, but (again) the form itself (c?...) or (c-formula...) screams that it is a formula that produces values for the slot. And as you acknowledge, :intiformula would be mutually exclusive with :initform, which suggests that in some very deep sense they are the same thing and should /not/ be specified by different keywords. the mere fact that the code now has to check for both and that we have sunk into a quagmire on how to resolve disputes in the class hierarchy suggests that :initformula would be a big mistake.
OK, but "Deeply Correct" I think not. A function is just another type of value. Its purpose in any given situation is defined by the /role/ it plays in that situation. :initform is a role in the object creation process. We shouldn't confuse the individual with some role played by the individual.
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.
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.
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 :-)