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

[Peter Denno]

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. 

-- 
- Best regards,
   Peter