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

[Peter Denno]

On Sunday 02 October 2005 22:13, Kenny Tilton wrote:
> Peter Denno wrote:
> >On Sunday 02 October 2005 01:54, Kenny Tilton wrote:
> >
> >
> >Thanks, that was helpful. But I am still looking for a definition that
> > nails the distinction. A definition is a single sentence that
> > distinguishes a concept from other concepts in the domain of discourse.
> > ;^)
> >
> >How about this:
> >
> >The two define different kinds of cells:
> >
> >"A c-input cell is a cell whose value may be set through explicit
> > declarative code, such as by using setf on the slot."
>
> (a) I think you mean procedural, not declarative

Of course. Thanks.


> (b) "such as by using setf" sounds like there is some other way, but
> setf is the /only/ way. Note that (setf slot-value) is a backdoor
> operation which bypasses and pretty much breaks the Cells contract with
> users. So it is not an alternative to setf, and it is a Bad Idea.


>
> >"A c-formula cell is a cell whose value is obtained through evaluation of
> > a formula."
> >
> >Note that the usual semantics of :initform do not apply when :initform is
> >given by c-formula. Instead of just setting the value at initialization,
> > the c-formula (an arbitrary lisp form) specifies the dynamic relationship
> > between the slot's value and other aspects of the program state.
> >
> >[It's actually this last part that is worth noting, I think. The semantics
> >of :initform are different. IMO cells would be easier to learn had you not
> >used :initform for the purpose of associating a formula with the slot. --
> >though :initform and whatever other keyword you might use to specify the
> >c-formula would be mutually exclusive.]
>
> I like it. We could have a :formula option on slot definitions and
> generate a compile-time error if both initform and formula are
> specified. We then must also offer a :default-formulargs, generating an
> error if one duplicates a :default-initarg. But then how do we resolve
> conflicts where one subclass specifies a default-initarg for a slot
> which has been given a :formula, or vice versa, or a sub--sub-class goes
> with a :default-formularg and a subclass went with default-initarg?
>
> 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'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).

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

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.

>
> >k. tilton:
> >
> >Last I looked, Cells-Gtk did not work much like a spreadsheet.
> >
> >
> >p. denno:
> >
> >If you could find any spot where we might use cells more effectively, I'll
> > try to fix it.
>
> I am a little maxed out now, but:
>
> - to a large degree, there are two things at work in a cells-gtk app. The
> widgets all work together nicely. Cells helps. Ain't broke, don't fix,
> because ideally this code becomes stable and does not get in the way of
> other development. (I /would/ however be concerned if this ouput setf'ing
> became standard practice in the second thing, application code managing app
> semantics amongst multiple GYI widgets
>
> - look for output methods setf'ing c-input cells. Decide if the setf'ed
> slots could be written as rules.
>
> - I myself use setf in output methods only where A depends on B and B
> depends on A. A scroll bar can control the text, or the text cursor
> positiion can decide the text. If that circumstance does not hold, look to
> see if the value can be expressed as a rule.

Thanks. I'll take a look.

-- 
- Best regards,
   Peter