[cells-devel] my very first baby steps with cells

[Kenny Tilton]

Friedrich Dominicus wrote:

>Ok, the learning curve is steep and my idea on what I'm doing is less
>then basic. However here we go, this is the code
>(defmodel foobar (model)
>  ((val-1 :cell t :accessor val-1 :initform "" :initarg :val-1)
>   (val-3 :cell t :accessor val-3 :initarg :val-3 :initform (c-in "Initialize"))))
>
>                     
>
>
>(def-c-output val-1 ()
>  (format t "val-1 is ~a, val-3 is ~a~%" 
>          (val-1 self) (val-3 self)))
>
>
>
>(defun foo-test ()
>  (cell-reset)
>  (let ((obj (make-instance 'foobar
>                            :val-1 (c? (if (val-3 self)
>                                           (setf (val-1 self) (val-3 self))
>                                           "val-3 not set")))))
>
Just use: (c? (or (val-3 self) "val-3 not set"))
There is also a handy macro for cells of oneself: (c? (or (^val-3) 
"val-3 not set"))

The Cell engine populates the slot at the right time (long story, but 
the timing is delicate) initially and as val-3 changes.

Note that there is a runtime error generated when you attempt to SETF a 
ruled Cell, as your rule is doing (SETFing itself!), but I think at some 
point recently I changed things so the error is enforced only if 
*c-debug* is non-nil. Recall is fuzzy on why I did that.

Anyway, the idea is to have a declarative approach in which one supplies 
a rule for a slot and then the Cells engine takes over and keeps things 
in synch.

>    
>    (setf (val-3 obj) "another val-3")
>    (setf (val-3 obj) "yet another val for val-3"))
>  (values))
>
>In this utterly primitive example the val3 slot "steers" the slot-1
>slot. 
>
Think of it as slot-1 "following" val3. Note that there is no val-3 
logic to change val-1. val-3 does not know anything about val-1. But 
val-1 has a rule that uses val-3. val-1 could have also used any number 
of other vals. This is important, and really constitutes the paradigm 
shift away from a procedural, manual SETFing of other values to a 
declarative "just worry about the rule for one value at a time".

>Translated to my need to sync db-view and "user-view", I assume
>I have to write  model with the two objects in it do the
>initialization from one side (e.g populating from the database), I
>probably also have to write a function to feed to the :unchanged (or
>so slot), if that yiels true, then the view and database data are in
>sync if not I have to update the database data from the view. 
>
I am afraid you lost me there. "two objects"? "one side"? Maybe once you 
have absorbed the above correction and otherwise gottten a better 
understanding of the declarative model we can try some actual 
unambiguous code using a simple text file as a database, with each line 
constituting a row in an SQL table. I guess the principle will be the 
same, and this would be a rather extreme but illuminating Use Case to 
share with others.

Note that the original code I described was proprietary, so we would 
develop new code from scratch (and I cannot share the old code).

-- 
Kenny

Why Lisp? http://wiki.alu.org/RtL_Highlight_Film

"I've wrestled with reality for 35 years, Doctor, and I'm happy to state I finally won out over it."
    Elwood P. Dowd, "Harvey", 1950