[cells-gtk-devel] Re: [cells-devel] Use of :initform c? and c-in

[Thomas F. Burdick]

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 :-)

-- 
           /|_     .-----------------------.                        
         ,'  .\  / | Free Mumia Abu-Jamal! |
     ,--'    _,'   | Abolish the racist    |
    /       /      | death penalty!        |
   (   -.  |       `-----------------------'
   |     ) |                               
  (`-.  '--.)                              
   `. )----'