From tfb at OCF.Berkeley.EDU Sat May 8 18:29:26 2004 From: tfb at OCF.Berkeley.EDU (Thomas F. Burdick) Date: Sat, 08 May 2004 18:29:26 -0000 Subject: [cells-devel] Constructor syntax In-Reply-To: Kenny Tilton's message of "Fri, 07 May 2004 02:29:04 GMT" References: Message-ID: Kenny Tilton writes: > nikodemus at random-state.net wrote: > > > This is quite off-topic for the thread, but I for one always cringe when I > > see Cells code due to C? and friends. > > > > If the syntax were: > > > > RULE-LAMBDA (binding) form* > > > > or > > > > RULE-LAMBDA binding form* > > Garnet's KR had (I forget)-formula. But when one is /really/ using > Cells, one is spraying CVs and C?s around all the time, and this is more > a candidate for something like collapsing QUOTE into ' or FUNCTION into > #' then it is expansion into big-huge-name useful at the application > level where, as we all know, excessive abbreviation saves so very little > and detracts so much from readability. > > That said, if some contributor wanted to create c-formula and c-variable > macros and add them to Cells I would not mind. Okay, how are these for a start? (defmacro cv (&optional (value +unbound+)) `(cells::make-c-variable :value ,value)) (defmacro c-formula ((&rest keys &key lazy cyclic-p cyclic-value) &body forms) (declare (ignore lazy cyclic-p cyclic-value)) `(cells::make-c-dependent :code ',forms :rule (c-lambda , at forms) , at keys)) (defmacro c-variable ((&rest keys &key cyclic-p) &optional (value nil valuep)) (declare (ignore cyclic-p)) `(cells::make-c-variable :value ,(if valuep value '+unbound+) , at keys)) They don't capture all the options (yet), but syntactically I think I like it. I agree that cv and c? are so common they should have their own short abbreviations. However, c?_8... seems like maybe not the best road syntactically. This syntax has the advantage of not needing to export a new macro if more options are added later (not that I can think of any types of cells still missing, of the top of my head). Actually, I just changed my code to use c-formula instead of c?_, and I like it. It even saves me two columns of horizontal space. I have no desire to change my c? forms, but it's not like my lazy formulas were one-liners anyway. From ktilton at nyc.rr.com Sun May 9 06:02:16 2004 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Sun, 09 May 2004 02:02:16 -0400 Subject: [cells-devel] Re: [cello-devel] Constructor syntax In-Reply-To: References: Message-ID: <409DC968.2060402@nyc.rr.com> Thomas F. Burdick wrote: >Kenny Tilton writes: > > > >>nikodemus at random-state.net wrote: >> >> >> >>>This is quite off-topic for the thread, but I for one always cringe when I >>>see Cells code due to C? and friends. >>> >>>If the syntax were: >>> >>> RULE-LAMBDA (binding) form* >>> >>> or >>> >>> RULE-LAMBDA binding form* >>> >>> >>Garnet's KR had (I forget)-formula. But when one is /really/ using >>Cells, one is spraying CVs and C?s around all the time, and this is more >>a candidate for something like collapsing QUOTE into ' or FUNCTION into >>#' then it is expansion into big-huge-name useful at the application >>level where, as we all know, excessive abbreviation saves so very little >>and detracts so much from readability. >> >>That said, if some contributor wanted to create c-formula and c-variable >>macros and add them to Cells I would not mind. >> >> > >Okay, how are these for a start? > > (defmacro cv (&optional (value +unbound+)) > `(cells::make-c-variable :value ,value)) > > (defmacro c-formula ((&rest keys &key lazy cyclic-p cyclic-value) &body forms) > (declare (ignore lazy cyclic-p cyclic-value)) > `(cells::make-c-dependent :code ',forms :rule (c-lambda , at forms) > , at keys)) > > (defmacro c-variable ((&rest keys &key cyclic-p) &optional (value nil valuep)) > (declare (ignore cyclic-p)) > `(cells::make-c-variable :value ,(if valuep value '+unbound+) , at keys)) > looks ok. but... 1. Is there a definition for +unbound+ missing? 2. Maybe if I stare at it long enough it will come to me, but why not do on c-variable what is proposed for cv, viz.,: &optional (value '+unbound+) kt From tfb at OCF.Berkeley.EDU Mon May 10 23:35:35 2004 From: tfb at OCF.Berkeley.EDU (Thomas F. Burdick) Date: Mon, 10 May 2004 16:35:35 -0700 Subject: [cells-devel] Re: [cello-devel] Constructor syntax In-Reply-To: <409DC968.2060402@nyc.rr.com> References: <409DC968.2060402@nyc.rr.com> Message-ID: <16544.4551.557339.979433@famine.OCF.Berkeley.EDU> Kenny Tilton writes: > Thomas F. Burdick wrote: > > >Okay, how are these for a start? > > > > (defmacro cv (&optional (value +unbound+)) > > `(cells::make-c-variable :value ,value)) > > > > (defmacro c-formula ((&rest keys &key lazy cyclic-p cyclic-value) &body forms) > > (declare (ignore lazy cyclic-p cyclic-value)) > > `(cells::make-c-dependent :code ',forms :rule (c-lambda , at forms) > > , at keys)) > > > > (defmacro c-variable ((&rest keys &key cyclic-p) &optional (value nil valuep)) > > (declare (ignore cyclic-p)) > > `(cells::make-c-variable :value ,(if valuep value '+unbound+) , at keys)) > > looks ok. but... > > 1. Is there a definition for +unbound+ missing? > > 2. Maybe if I stare at it long enough it will come to me, but why not do > on c-variable what is proposed for cv, viz.,: > > &optional (value '+unbound+) Hmm, maybe I should have edited these on their way out of my utils file. +unbound+ is from (defconstant +unbound+ '+unbound+), from my unbound-cells hack from before. As for (2), yeah, that would be simpler. It was a mental-cut-and-paste error, from having written a bunch of macros right before that, that needed the supplied-p value. From ktilton at nyc.rr.com Tue May 11 00:08:57 2004 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Mon, 10 May 2004 20:08:57 -0400 Subject: [cells-devel] Re: [cello-devel] Constructor syntax In-Reply-To: <16544.4551.557339.979433@famine.OCF.Berkeley.EDU> References: <409DC968.2060402@nyc.rr.com> <16544.4551.557339.979433@famine.OCF.Berkeley.EDU> Message-ID: <40A01999.8000302@nyc.rr.com> Thomas F. Burdick wrote: >Kenny Tilton writes: > > > Thomas F. Burdick wrote: > > > > >Okay, how are these for a start? > > > > > > (defmacro cv (&optional (value +unbound+)) > > > `(cells::make-c-variable :value ,value)) > > > > > > (defmacro c-formula ((&rest keys &key lazy cyclic-p cyclic-value) &body forms) > > > (declare (ignore lazy cyclic-p cyclic-value)) > > > `(cells::make-c-dependent :code ',forms :rule (c-lambda , at forms) > > > , at keys)) > > > > > > (defmacro c-variable ((&rest keys &key cyclic-p) &optional (value nil valuep)) > > > (declare (ignore cyclic-p)) > > > `(cells::make-c-variable :value ,(if valuep value '+unbound+) , at keys)) > > > > looks ok. but... > > > > 1. Is there a definition for +unbound+ missing? > > > > 2. Maybe if I stare at it long enough it will come to me, but why not do > > on c-variable what is proposed for cv, viz.,: > > > > &optional (value '+unbound+) > >Hmm, maybe I should have edited these on their way out of my utils >file. +unbound+ is from (defconstant +unbound+ '+unbound+), from my >unbound-cells hack from before. As for (2), yeah, that would be >simpler. > if you want to send me something with these two amendments I will manually merge with the Cells I have here, currently a subdirectory of Cello, and then future Cello/Cells releases will have that. I guess I am still leaning towards that structure, in which Cells can be accessed indepenendently but from within the larger Cello context. In fact, maybe there is a pattern here: every big huge library can choose one and only one big huge parent library which depends crucially on it, and likely will have only one plausible candidate parent. Wouldn't that be an interesting law of software architecture, if in fact the latter proved true? eg, cl-typesetting being a natural container for cl-pdf, and cello being a natural for cells. kt -- Home? http://tilton-technology.com Cells? http://www.common-lisp.net/project/cells/ Cello? http://www.common-lisp.net/project/cello/ Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film Your Project Here! http://alu.cliki.net/Industry%20Application From tfb at OCF.Berkeley.EDU Tue May 11 22:52:51 2004 From: tfb at OCF.Berkeley.EDU (Thomas F. Burdick) Date: Tue, 11 May 2004 15:52:51 -0700 Subject: [cells-devel] Re: [cello-devel] Constructor syntax In-Reply-To: <40A01999.8000302@nyc.rr.com> References: <409DC968.2060402@nyc.rr.com> <16544.4551.557339.979433@famine.OCF.Berkeley.EDU> <40A01999.8000302@nyc.rr.com> Message-ID: <16545.22851.946934.988654@famine.OCF.Berkeley.EDU> Kenny Tilton writes: > if you want to send me something with these two amendments I will > manually merge with the Cells I have here, currently a subdirectory of > Cello, and then future Cello/Cells releases will have that. I guess I am > still leaning towards that structure, in which Cells can be accessed > indepenendently but from within the larger Cello context. Coolio, let's get it in CVS, over in Cello-land, then. I tried to add unbound-cells support to Cells itself, and I think it works, but I wasn't expecting it to. In short: (defmodel adder () ((x :accessor adder-x :initform (cv)) (y :accessor adder-y :initform (cv)) (sum :accessor adder-sum :initform (c? (+ (^adder-x) (^adder-y)))))) (defparameter >>adder (to-be (make-instance 'adder))) (setf (adder-x >>adder) 0) The above happily works. It doesn't trigger the rule until I do: (adder-sum >>adder) => Am I crazy, or shouldn't it have given me that when I set adder-x to 0? Even if I am crazy, and that should work fine, one change does need to be made: cells doesn't currently catch the unbound-cell errors, because I wasn't sure where in the propagation code to put it. Here are my changes: ========== in cells.lisp (defconstant +unbound+ '+unbound+) (define-condition unbound-cell (unbound-slot) ()) ========== in cell-types.lisp (defmacro c-formula ((&rest keys &key lazy cyclic-p cyclic-value) &body forms) (declare (ignore lazy cyclic-p cyclic-value)) `(make-c-dependent :code ',forms :rule (c-lambda , at forms) , at keys)) (defmacro c-variable ((&rest keys &key cyclic-p) &optional (value +unbound+)) (declare (ignore cyclic-p)) `(make-c-variable :value ,value , at keys)) (defmacro cv (&optional (defn +unbound+)) `(make-c-variable :value ,defn)) ;; use c-independent if need deferred execution ========== in defmodel.lisp =============== this isn't particularly related, it just quiets down =============== SBCL a little. ; ; ------- defclass --------------- (^slot-value ,model ',',slotname) ; (progn (defclass ,class ,(or directsupers '(model-object));; now we can def the class ,(mapcar (lambda (s) (list* (car s) (let ((ias (cdr s))) ;; We handle accessor below (when (getf ias :cell t) (remf ias :reader) (remf ias :writer) (remf ias :accessor)) (remf ias :cell) (remf ias :cwhen) (remf ias :unchanged-if) ias))) (mapcar #'copy-list slotspecs)) (:documentation ,@(or (cdr (find :documentation options :key #'car)) '("chya"))) (:default-initargs ;; nil ok and needed: acl oddity in re not clearing d-i's sans this ,@(cdr (find :default-initargs options :key #'car))) (:metaclass ,(or (find :metaclass options :key #'car) 'standard-class))) ========== in md-slot-value.lisp =============== in defun md-slot-value ; this next bit is not written (c-relay-value (etypecase slot-c...)) ; because that would link before accessing possibly an invalid ruled slot ; (during md-awaken), and after calculating it would propagate to users and ; re-enter this calculation. Switching the order of the parameters would ; also work, but we need to document this very specific order of operations ; anyway, can't just leave that to the left-right thing. ; (let ((slot-value (etypecase slot-c (null (bd-slot-value self slot-spec)) (c-variable (c-value slot-c)) (c-ruled (c-ruled-slot-value slot-c))))) (format *debug-io* "slot ~S of ~S is ~S" self slot-spec slot-value) (when (eql slot-value +unbound+) (error 'unbound-cell :instance self :name slot-spec)) (c-relay-value (when (car *c-calculators*) (c-link-ex slot-c)) slot-value))) ========== in model-object.lisp (defun c-install (self sn c) (assert (typep c 'cell)) (trc nil "installing cell" sn c) (setf (c-model c) self (c-slot-spec c) sn (md-slot-cell self sn) c (slot-value self sn) (when (typep c 'c-variable) (c-value c))) (when (eql (slot-value self sn) +unbound+) (slot-makunbound self sn))) Phew! Okay, I'm making sure I only edit verion-controlled source from now on, so I can make Emacs do the differencing work for me. From tfb at OCF.Berkeley.EDU Tue May 11 22:58:00 2004 From: tfb at OCF.Berkeley.EDU (Thomas F. Burdick) Date: Tue, 11 May 2004 15:58:00 -0700 Subject: [cells-devel] Re: [cello-devel] Constructor syntax In-Reply-To: <16545.22851.946934.988654@famine.OCF.Berkeley.EDU> References: <409DC968.2060402@nyc.rr.com> <16544.4551.557339.979433@famine.OCF.Berkeley.EDU> <40A01999.8000302@nyc.rr.com> <16545.22851.946934.988654@famine.OCF.Berkeley.EDU> Message-ID: <16545.23160.354644.242752@famine.OCF.Berkeley.EDU> Thomas F. Burdick writes: > (let ((slot-value (etypecase slot-c > (null (bd-slot-value self slot-spec)) > (c-variable (c-value slot-c)) > (c-ruled (c-ruled-slot-value slot-c))))) > (format *debug-io* "slot ~S of ~S is ~S" self slot-spec slot-value) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > (when (eql slot-value +unbound+) > (error 'unbound-cell :instance self :name slot-spec)) *sigh* I thought I'd gotten all my debugging notes out of there. From ktilton at nyc.rr.com Wed May 12 15:12:20 2004 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Wed, 12 May 2004 11:12:20 -0400 Subject: [cells-devel] Re: [cello-devel] Constructor syntax In-Reply-To: <16545.22851.946934.988654@famine.OCF.Berkeley.EDU> References: <409DC968.2060402@nyc.rr.com> <16544.4551.557339.979433@famine.OCF.Berkeley.EDU> <40A01999.8000302@nyc.rr.com> <16545.22851.946934.988654@famine.OCF.Berkeley.EDU> Message-ID: <40A23ED4.8020901@nyc.rr.com> Thomas F. Burdick wrote: > (defmodel adder () > ((x :accessor adder-x :initform (cv)) > (y :accessor adder-y :initform (cv)) > (sum :accessor adder-sum :initform (c? (+ (^adder-x) (^adder-y)))))) > > (defparameter >>adder (to-be (make-instance 'adder))) > > (setf (adder-x >>adder) 0) > >The above happily works. It doesn't trigger the rule until I do: > > (adder-sum >>adder) > => > Add: (def-c-echo sum () (print (list self new-value old-value))) ...and you'll get the error when to-be runs. I added your code. My c-install had evolved a little, so I just added the make-unbound. I see you /had/ handle things on the read side, so I am trying to remember what we had talked about on the propagation side: >need to be made: cells doesn't currently catch the unbound-cell >errors, because I wasn't sure where in the propagation code to put it. > The above is confusing. Cells (with your additions) certainly does catch reads of unbound cells, as you noted once you accessed adder-sum. kt From tfb at OCF.Berkeley.EDU Thu May 13 00:01:46 2004 From: tfb at OCF.Berkeley.EDU (Thomas F. Burdick) Date: Wed, 12 May 2004 17:01:46 -0700 Subject: [cells-devel] Re: [cello-devel] Constructor syntax In-Reply-To: <40A23ED4.8020901@nyc.rr.com> References: <409DC968.2060402@nyc.rr.com> <16544.4551.557339.979433@famine.OCF.Berkeley.EDU> <40A01999.8000302@nyc.rr.com> <16545.22851.946934.988654@famine.OCF.Berkeley.EDU> <40A23ED4.8020901@nyc.rr.com> Message-ID: <16546.47850.862990.802861@famine.OCF.Berkeley.EDU> Kenny Tilton writes: > > Thomas F. Burdick wrote: > > > (defmodel adder () > > ((x :accessor adder-x :initform (cv)) > > (y :accessor adder-y :initform (cv)) > > (sum :accessor adder-sum :initform (c? (+ (^adder-x) (^adder-y)))))) > > > > (defparameter >>adder (to-be (make-instance 'adder))) > > > > (setf (adder-x >>adder) 0) > > > >The above happily works. It doesn't trigger the rule until I do: > > > > (adder-sum >>adder) > > => > > Add: (def-c-echo sum () (print (list self new-value old-value))) > > ...and you'll get the error when to-be runs. Hmm, I get the error once. That is: (to-be (make-instance 'adder)) => (to-be (make-instance 'adder)) => ADDER > I added your code. My c-install had evolved a little, so I just added > the make-unbound. Cool. What I sent should be fine alone, it has the capabilities of the hack I'd been using. However, it would be cool to keep going, and have support for making slots unbound: > I see you /had/ handle things on the read side, so I > am trying to remember what we had talked about on the propagation side: > > >need to be made: cells doesn't currently catch the unbound-cell > >errors, because I wasn't sure where in the propagation code to put it. > > The above is confusing. Cells (with your additions) certainly does catch > reads of unbound cells, as you noted once you accessed adder-sum. I meant "doesn't handle conditions of type CELLS:UNBOUND-CELL". This doesn't come up in what I have so far, because of the nascent-cells thing that was throwing me. But, let's say we add a method on SLOT-MAKUNBOUND-USING-CLASS (or add a c-slot-makunbound function). If I call (slot-makunbound >>adder 'x), it should set X back to being unbound, and kick off the rule for SUM. At this point, something should handle the UNBOUND-CELL error, and make SUM unbound. Now, if I call ADDER-SUM, it should kick off SUM's rule again, and this time raise the UNBOUND-CELL error for X. I hadn't yet tried to figure out where to establish a handler for UNBOUND-CELL, because I was tripped out by my little example above. capite? From ktilton at nyc.rr.com Thu May 13 00:12:55 2004 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Wed, 12 May 2004 20:12:55 -0400 Subject: [cells-devel] Re: [cello-devel] Constructor syntax In-Reply-To: <16546.47850.862990.802861@famine.OCF.Berkeley.EDU> References: <409DC968.2060402@nyc.rr.com> <16544.4551.557339.979433@famine.OCF.Berkeley.EDU> <40A01999.8000302@nyc.rr.com> <16545.22851.946934.988654@famine.OCF.Berkeley.EDU> <40A23ED4.8020901@nyc.rr.com> <16546.47850.862990.802861@famine.OCF.Berkeley.EDU> Message-ID: <40A2BD87.7020606@nyc.rr.com> Thomas F. Burdick wrote: >Kenny Tilton writes: > > > > Thomas F. Burdick wrote: > > > > > (defmodel adder () > > > ((x :accessor adder-x :initform (cv)) > > > (y :accessor adder-y :initform (cv)) > > > (sum :accessor adder-sum :initform (c? (+ (^adder-x) (^adder-y)))))) > > > > > > (defparameter >>adder (to-be (make-instance 'adder))) > > > > > > (setf (adder-x >>adder) 0) > > > > > >The above happily works. It doesn't trigger the rule until I do: > > > > > > (adder-sum >>adder) > > > => > > > > Add: (def-c-echo sum () (print (list self new-value old-value))) > > > > ...and you'll get the error when to-be runs. > >Hmm, I get the error once. That is: > > (to-be (make-instance 'adder)) => > (to-be (make-instance 'adder)) => ADDER > Shut up! I can't wait to see this one. Gotta run out for a sec, but I'll look at this in a bit. > > > I added your code. My c-install had evolved a little, so I just added > > the make-unbound. > >Cool. What I sent should be fine alone, it has the capabilities of >the hack I'd been using. However, it would be cool to keep going, and >have support for making slots unbound: > ok, that's where I thought you were going. >I meant "doesn't handle conditions of type CELLS:UNBOUND-CELL". This >doesn't come up in what I have so far, because of the nascent-cells >thing that was throwing me. But, let's say we add a method on >SLOT-MAKUNBOUND-USING-CLASS (or add a c-slot-makunbound function). If >I call (slot-makunbound >>adder 'x), it should set X back to being >unbound, and kick off the rule for SUM. > right. > >At this point, something should handle the UNBOUND-CELL error, and >make SUM unbound. > well, I always get a kick out of digging and digging and finally there it is in all its simplicity: (funcall (c-rule c) self) ...or something like that. So that would be where the trap for unbounditude would go. > Now, if I call ADDER-SUM, it should kick off SUM's >rule again,.. > Why? rules get run when dependencies change or the state is unknown (only after make-instance, except for lazy cells which have been invalidated but not recalculated). The unbounditude is effectively a cached result, so there is no need to kick off the rule. > and this time raise the UNBOUND-CELL error for X. I >hadn't yet tried to figure out where to establish a handler for >UNBOUND-CELL, because I was tripped out by my little example above. > >capite? > > > kt From ktilton at nyc.rr.com Thu May 13 03:47:47 2004 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Wed, 12 May 2004 23:47:47 -0400 Subject: [cells-devel] Re: [cello-devel] Constructor syntax In-Reply-To: <16546.47850.862990.802861@famine.OCF.Berkeley.EDU> References: <409DC968.2060402@nyc.rr.com> <16544.4551.557339.979433@famine.OCF.Berkeley.EDU> <40A01999.8000302@nyc.rr.com> <16545.22851.946934.988654@famine.OCF.Berkeley.EDU> <40A23ED4.8020901@nyc.rr.com> <16546.47850.862990.802861@famine.OCF.Berkeley.EDU> Message-ID: <40A2EFE3.6060300@nyc.rr.com> Oops. After an error, *to-be-awakened* needs to be cleared in a protected form. That stuff is ugly, and I think Cells: The Next Generation will make that and other ugliness go away. For now, try this: (defun to-be (self) (trc "to-be> entry" self (md-state self)) (progn ;;wtrc (0 100 "to-be> entry" self (md-state self) (length *to-be-awakened*)) (when (eql :nascent (md-state self)) ;; formwithview to-be-primary :after => rv-stitch! => side-effects (let ((already *to-be-awakened*)) (setf *to-be-awakened* (nconc *to-be-awakened* (list self))) (unwind-protect (progn (trc nil "to-be deferring awaken" self) (kids self) ;; sick, just for side effect (unless already (trc nil "top to-be awakening deferred" self (length *to-be-awakened*)) (do* ((mds *to-be-awakened* (cdr mds)) (md (car mds) (car mds))) ((null mds)) (if (eql :nascent (md-state md)) (md-awaken md) (trc nil "not md-awakening non-nascent" md))))) (setf *to-be-awakened* nil))))) self) kt From tfb at OCF.Berkeley.EDU Thu May 13 06:35:33 2004 From: tfb at OCF.Berkeley.EDU (Thomas F. Burdick) Date: Wed, 12 May 2004 23:35:33 -0700 Subject: [cells-devel] Re: [cello-devel] Constructor syntax In-Reply-To: <40A2EFE3.6060300@nyc.rr.com> References: <409DC968.2060402@nyc.rr.com> <16544.4551.557339.979433@famine.OCF.Berkeley.EDU> <40A01999.8000302@nyc.rr.com> <16545.22851.946934.988654@famine.OCF.Berkeley.EDU> <40A23ED4.8020901@nyc.rr.com> <16546.47850.862990.802861@famine.OCF.Berkeley.EDU> <40A2EFE3.6060300@nyc.rr.com> Message-ID: <16547.5941.48109.522189@famine.OCF.Berkeley.EDU> Kenny Tilton writes: > Oops. After an error, *to-be-awakened* needs to be cleared in a > protected form. That stuff is ugly, and I think Cells: The Next > Generation will make that and other ugliness go away. > > For now, try this: Aiiight, that worked. Now that my expectation of what should happen, and what is happening are in sync, I'll dive back in, and finish the job. So ... uh, which approach do you think is worse: using a c-slot-makunbound function that works for both normal and cell-mediated slots; or including hacks to make MCL and CLISP go through slot-makunbound-using-class? From ktilton at nyc.rr.com Thu May 13 13:01:21 2004 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Thu, 13 May 2004 09:01:21 -0400 Subject: [cells-devel] Re: [cello-devel] Constructor syntax In-Reply-To: <16547.5941.48109.522189@famine.OCF.Berkeley.EDU> References: <409DC968.2060402@nyc.rr.com> <16544.4551.557339.979433@famine.OCF.Berkeley.EDU> <40A01999.8000302@nyc.rr.com> <16545.22851.946934.988654@famine.OCF.Berkeley.EDU> <40A23ED4.8020901@nyc.rr.com> <16546.47850.862990.802861@famine.OCF.Berkeley.EDU> <40A2EFE3.6060300@nyc.rr.com> <16547.5941.48109.522189@famine.OCF.Berkeley.EDU> Message-ID: <40A371A1.6020605@nyc.rr.com> Thomas F. Burdick wrote: >Kenny Tilton writes: > > Oops. After an error, *to-be-awakened* needs to be cleared in a > > protected form. That stuff is ugly, and I think Cells: The Next > > Generation will make that and other ugliness go away. > > > > For now, try this: > >Aiiight, that worked. Now that my expectation of what should happen, >and what is happening are in sync, I'll dive back in, and finish the >job. > >So ... uh, which approach do you think is worse: using a >c-slot-makunbound function that works for both normal and >cell-mediated slots; > In this contrast between normal and cell-mediated, does normal mean a slot specified: :cell nil or a potentially cell-mediatable slot of an instance in which the slot is not in fact mediated by a cell? :cell t :initform 42 The former would not hurt since we are trying hard to make Cell unbounditude work like CL's, tho I have as a bit of programmer-friendliness tended to respond "yo, this slot is specified ':cell nil'". [aside: is it c-slot-makunbound or md-slot-makunbound? I have both in re slot-value. md- takes the slot name, looks for a cell, calls c- if it finds one. By that parallel we are talkin bout md-slot-value] > or including hacks to make MCL and CLISP go >through slot-makunbound-using-class? > Hunh? MCL does not /have/ a slot-makunbound-using-class (he guessed based on MCL not exposing much of the MOP). How can you make MCL go thru what it does not have? ie, if (i am guessing) slot-makunbound is a function, how do you change its behavior? advise (which is one corner of Lisp I have never visited)? Golly I wish the MOP were part of the standard. kt From tfb at OCF.Berkeley.EDU Fri May 14 06:23:20 2004 From: tfb at OCF.Berkeley.EDU (Thomas F. Burdick) Date: Thu, 13 May 2004 23:23:20 -0700 Subject: [cells-devel] Re: [cello-devel] Constructor syntax In-Reply-To: <40A371A1.6020605@nyc.rr.com> References: <409DC968.2060402@nyc.rr.com> <16544.4551.557339.979433@famine.OCF.Berkeley.EDU> <40A01999.8000302@nyc.rr.com> <16545.22851.946934.988654@famine.OCF.Berkeley.EDU> <40A23ED4.8020901@nyc.rr.com> <16546.47850.862990.802861@famine.OCF.Berkeley.EDU> <40A2EFE3.6060300@nyc.rr.com> <16547.5941.48109.522189@famine.OCF.Berkeley.EDU> <40A371A1.6020605@nyc.rr.com> Message-ID: <16548.26072.902183.122808@famine.OCF.Berkeley.EDU> Kenny Tilton writes: > > Thomas F. Burdick wrote: > > >So ... uh, which approach do you think is worse: using a > >c-slot-makunbound function that works for both normal and > >cell-mediated slots; > > In this contrast between normal and cell-mediated, does normal mean a > slot specified: > > :cell nil I still need to work on my Cells-related terminology; I mean this case. That way Cells-using programs could use the same makunbound for all objects, without worrying about where they came from. > [aside: is it c-slot-makunbound or md-slot-makunbound? I have both in re > slot-value. md- takes the slot name, looks for a cell, calls c- if it > finds one. By that parallel we are talkin bout md-slot-value] Yeah, I guess it would be md-slot-makunbound, considering you get to the slot with md-slot-value. > > or including hacks to make MCL and CLISP go > >through slot-makunbound-using-class? > > Hunh? MCL does not /have/ a slot-makunbound-using-class (he guessed > based on MCL not exposing much of the MOP). How can you make MCL go thru > what it does not have? ie, if (i am guessing) slot-makunbound is a > function, how do you change its behavior? advise (which is one corner of > Lisp I have never visited)? > > Golly I wish the MOP were part of the standard. (No kidding). Well, MCL doesn't /ship/ with s-m-u-c ... but it does have enough of a MOP to write one. Then, once such a beast is written, slot-makunbound can be redefined to go through it. In fact, I have such a beast from my previous MCL adventures. Those with sensitive constitutions may want to skip this: (defpackage :s-m-u-c-patch (:use :common-lisp :ccl)) (in-package :s-m-u-c-patch) (unless (fboundp 'ccl::slot-makunbound-using-class) (unless (fboundp '%slot-makunbound) (setf (symbol-function '%slot-makunbound) (symbol-function 'slot-makunbound))) (defgeneric ccl::slot-makunbound-using-class (class object slotd) (:method ((class standard-class) object (slotd cons)) (%slot-makunbound object (slot-definition-name slotd)))) (handler-bind ((error (lambda (e) (let ((do-it (find-restart 'continue e))) (when do-it (invoke-restart do-it)))))) (defun slot-makunbound (object slot) (let* ((class (class-of object)) (slotd (or (find slot (class-instance-slots class) :key #'slot-definition-name) (slot-missing class object slot 'slot-makunbound)))) (ccl::slot-makunbound-using-class class object slotd)))) (export '(ccl::slot-makunbound-using-class) :ccl)) But, uhm, it does work. It's evil in a good way? Personally, I'd go with slot-makunbound-using-class, and hack it into systems missing it (obviously, since I load the above code in my MCL init file). But if you find that to be in bad taste, I could do the md-slot-makunbound route. *I* think I have great taste, but not everyone always agrees; some people prefer to fake the funk. From ktilton at nyc.rr.com Fri May 14 07:24:35 2004 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Fri, 14 May 2004 03:24:35 -0400 Subject: [cells-devel] Re: [cello-devel] Constructor syntax In-Reply-To: <16548.26072.902183.122808@famine.OCF.Berkeley.EDU> References: <409DC968.2060402@nyc.rr.com> <16544.4551.557339.979433@famine.OCF.Berkeley.EDU> <40A01999.8000302@nyc.rr.com> <16545.22851.946934.988654@famine.OCF.Berkeley.EDU> <40A23ED4.8020901@nyc.rr.com> <16546.47850.862990.802861@famine.OCF.Berkeley.EDU> <40A2EFE3.6060300@nyc.rr.com> <16547.5941.48109.522189@famine.OCF.Berkeley.EDU> <40A371A1.6020605@nyc.rr.com> <16548.26072.902183.122808@famine.OCF.Berkeley.EDU> Message-ID: <40A47433.8080304@nyc.rr.com> Thomas F. Burdick wrote: >Kenny Tilton writes: > > > > Thomas F. Burdick wrote: > > > > >So ... uh, which approach do you think is worse: using a > > >c-slot-makunbound function that works for both normal and > > >cell-mediated slots; > > > > In this contrast between normal and cell-mediated, does normal mean a > > slot specified: > > > > :cell nil > >I still need to work on my Cells-related terminology; I mean this >case. That way Cells-using programs could use the same makunbound for >all objects, without worrying about where they came from. > OK. And you mean "all slots", as well. Food for thought: slot-value is a back door. Not sure what that food means, tho, because for a while Cells /was/ mop-based and slot-value was not a back door. But that was slower and less portable. But those are practical concerns, not ideological. But consistency here might be a Good Thing if only for consistency's usual merits (hobgoblins notwithstanding). More food: when slot-value was /not/ a backdoor, it was a nuisance to programming cells. I had to set a *backdoor* special to actually get the raw slot-value in Cell internals. ie, slot-value-using-class and its setter both had to (in all specializations) keep an eye out for *backdoor* access. OK, it is not the end of the world, but it may have been a Message From God, viz, that perhaps the transparency thing (making it seem as if CLOS does Cells) is a mistake: CLOS does /not/ do Cells. Cells by this thinking are not strictly an /extension/ of CLOS, but rather a distinct OO capability implemented thru CLOS. Less profoundly, should Cell internals ever care about slot bounditude, we'll be back into *backdoor* tricks. Having to hack MCL folks' CLOSes becomes just another straw on the back at this point. Thoughts? kt -- Home? http://tilton-technology.com Cells? http://www.common-lisp.net/project/cells/ Cello? http://www.common-lisp.net/project/cello/ Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film Your Project Here! http://alu.cliki.net/Industry%20Application From ktilton at nyc.rr.com Fri May 14 08:01:08 2004 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Fri, 14 May 2004 04:01:08 -0400 Subject: [cells-devel] Major Cells fix (?) Message-ID: <40A47CC4.7010709@nyc.rr.com> I decided to address something about Cells I recently decided was Not Good: The echo of a cell (something conceived to permit side-effects outside the model dataflow) is permitted to kick off top-level (if you will) dataflow by setting some c-variable-mediated other slot. Fine. But echos run immediately after a new value has been assumed by a cell, before propagation to other cells. So what we had was echo-initiated top-level dataflow running to completion before the dataflow being echoed really got very far off the ground. And, yes, some very tricky misbehavior resulted, and I think is responsible for a lot of nasty code in Cells. Anyway, tonight I hacked a quick single-threading of such things: (defun (setf md-slot-value) ..... ...unchanged testing for cyclicity.... (let ((absorbed-value (c-absorb-value c new-value))) ;; dicey: decide absorbed-value now or just before setf? ;; ...but we need a value to return even if actual setf will be deferred. ;; (count-it :md-slot-value-setf slot-spec) (if *df-entry* (progn (nconc *df-entry* (list (cons c (cons absorbed-value *cause*)))) absorbed-value) (let ((*df-entry* (list nil))) (c-slot-value-absorb c absorbed-value) (loop for (c-deferred . (deferred-value . echoing-asker)) in (cdr *df-entry*) do (let ((*cause* echoing-asker)) ;; sketchy (c-slot-value-absorb c-deferred deferred-value))) absorbed-value)))))) (defun c-slot-value-absorb (c absorbed-value) (with-dataflow-management (c) (md-slot-value-assume (c-model c) (c-slot-spec c) absorbed-value))) "absorb"? "assume"? gotta work on that. The light panel still works, but tracing shows not a lot of very challenging cases. RoboCup was the worst stress test Cells has gotten, stumping it easily even after seven years of refinement. I may dust off TeamKenny to see what I can see. I prefer real-world stressors to artifices. Actually, what I should do is disable all the "m/cmdead" testing, which I believe arose to handle problems caused only by overlapping dataflow steps: some echo would cause some instance (the active player task) to leave the model (supplanted or completed), but already in the call stack was code that was going to be operating on those instances in some way shape or form. So in a mad dash before ILC 2003 I ended up sprinkling "dead" tests about thirty times around the system. My hope is that this new patch will clear the dataflow propagation stack before the echo zaps the instance. More to come, I guess. kt -- Home? http://tilton-technology.com Cells? http://www.common-lisp.net/project/cells/ Cello? http://www.common-lisp.net/project/cello/ Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film Your Project Here! http://alu.cliki.net/Industry%20Application From tfb at OCF.Berkeley.EDU Fri May 14 09:21:33 2004 From: tfb at OCF.Berkeley.EDU (Thomas F. Burdick) Date: Fri, 14 May 2004 02:21:33 -0700 Subject: [cells-devel] Re: [cello-devel] Constructor syntax In-Reply-To: <40A2BD87.7020606@nyc.rr.com> References: <409DC968.2060402@nyc.rr.com> <16544.4551.557339.979433@famine.OCF.Berkeley.EDU> <40A01999.8000302@nyc.rr.com> <16545.22851.946934.988654@famine.OCF.Berkeley.EDU> <40A23ED4.8020901@nyc.rr.com> <16546.47850.862990.802861@famine.OCF.Berkeley.EDU> <40A2BD87.7020606@nyc.rr.com> Message-ID: <16548.36765.598005.603176@famine.OCF.Berkeley.EDU> Kenny Tilton writes: > Thomas F. Burdick wrote: > > >At this point, something should handle the UNBOUND-CELL error, and > >make SUM unbound. > > well, I always get a kick out of digging and digging and finally there > it is in all its simplicity: > > (funcall (c-rule c) self) > > ...or something like that. So that would be where the trap for > unbounditude would go. > > > Now, if I call ADDER-SUM, it should kick off SUM's > >rule again,.. > > Why? rules get run when dependencies change or the state is unknown > (only after make-instance, except for lazy cells which have been > invalidated but not recalculated). The unbounditude is effectively a > cached result, so there is no need to kick off the rule. Good point. I was thinking we'd kick of the rule here, so the user could see which slot was ultimately responsible for the unbound error -- but we can just cache that information, hell, cache the condition itself, and signal it when needed. From tfb at OCF.Berkeley.EDU Fri May 14 09:43:39 2004 From: tfb at OCF.Berkeley.EDU (Thomas F. Burdick) Date: Fri, 14 May 2004 02:43:39 -0700 Subject: [cells-devel] Re: [cello-devel] Constructor syntax In-Reply-To: <40A47433.8080304@nyc.rr.com> References: <409DC968.2060402@nyc.rr.com> <16544.4551.557339.979433@famine.OCF.Berkeley.EDU> <40A01999.8000302@nyc.rr.com> <16545.22851.946934.988654@famine.OCF.Berkeley.EDU> <40A23ED4.8020901@nyc.rr.com> <16546.47850.862990.802861@famine.OCF.Berkeley.EDU> <40A2EFE3.6060300@nyc.rr.com> <16547.5941.48109.522189@famine.OCF.Berkeley.EDU> <40A371A1.6020605@nyc.rr.com> <16548.26072.902183.122808@famine.OCF.Berkeley.EDU> <40A47433.8080304@nyc.rr.com> Message-ID: <16548.38091.243470.340547@famine.OCF.Berkeley.EDU> Kenny Tilton writes: > Food for thought: slot-value is a back door. Not sure what that food > means, tho, because for a while Cells /was/ mop-based and slot-value was > not a back door. But that was slower and less portable. But those are > practical concerns, not ideological. But consistency here might be a > Good Thing if only for consistency's usual merits (hobgoblins > notwithstanding). > > More food: when slot-value was /not/ a backdoor, it was a nuisance to > programming cells. I had to set a *backdoor* special to actually get the > raw slot-value in Cell internals. ie, slot-value-using-class and its > setter both had to (in all specializations) keep an eye out for > *backdoor* access. OK, it is not the end of the world, but it may have > been a Message From God, viz, that perhaps the transparency thing > (making it seem as if CLOS does Cells) is a mistake: CLOS does /not/ do > Cells. Cells by this thinking are not strictly an /extension/ of CLOS, > but rather a distinct OO capability implemented thru CLOS. Less > profoundly, should Cell internals ever care about slot bounditude, we'll > be back into *backdoor* tricks. Hmmm ... maybe you're right. Exporting md-slot-value and making it bottom out to calling slot-value would make this argument stronger. Then, if you're using Cells, just use the md- variations for everything. If you're consuming object that you don't know too much about (are they Models?), you really don't want to be doing things like calling slot-value on them anyway. > Having to hack MCL folks' CLOSes becomes just another straw on the back > at this point. > > Thoughts? Well, I do think it's more like a bug in MCL, since it's in line with the MOP they implement, but on reconsideration, the md- solution might be better. Since Cells really isn't integrated into CLOS, having this little feature integrated would be weird; the normal backdoor around it would be to write a method on s-m-u-c that circumvents Cells'. But since model classes aren't instances of a model-class metaclass, the backdoor would be to get an :around method around the Cells :around method ... okay, that might just be a message from Rakim (God MC). --- /|_ .---------------------------------. ,' .\ / | It's been a long time, | ,--' _,' | I shouldn'ta left you | / / | without a dope rhyme to step to | ( -. | `---------------------------------' | ) | (`-. '--.) `. )----' From ktilton at nyc.rr.com Wed May 19 13:41:12 2004 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Wed, 19 May 2004 09:41:12 -0400 Subject: [cells-devel] Call for Cells Regression Test Suite Additions Message-ID: <40AB63F8.4010903@nyc.rr.com> This is mostly for Thomas who is actually using a couple of features I have added to Keep Other People Happy, but I thought the list would be interested... I am ripping out the disgusting dataflow-interference code. The bad news is that if I succeed I will have to kill myself, because the replacement solution is about ten lines of code /and/ works better, whereas you just need to look at the original code to see what a nightmare it was getting that to work. Anyway, it occurs to me the regression test does not include any checking of either lazy cells or unbounditude handling. Speaking of laziness, I probably will not do tests for those on my own, so if you would like Cells II tested out before release for either of those please send along some tests. It would be nice if they worked via cv-assert. Note that in some places I also confirm that an error is produced on deliberate no-nos. You might want to do some of that, too. kenny -- Home? http://tilton-technology.com Cells? http://www.common-lisp.net/project/cells/ Cello? http://www.common-lisp.net/project/cello/ Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film Your Project Here! http://alu.cliki.net/Industry%20Application From ktilton at nyc.rr.com Thu May 20 14:23:58 2004 From: ktilton at nyc.rr.com (Kenny Tilton) Date: Thu, 20 May 2004 10:23:58 -0400 Subject: [cells-devel] cv-laziness Message-ID: <40ACBF7E.8080900@nyc.rr.com> Oops, just noticed I did do a cv-laziness regression test, which has now been added to cv-test and still works under Cells II (the (so far) marvelous revision eliminating a whole lot of really dumb code). Anyone interested in the lazy thing can add to the that, or just do their own separate test. kt -- Home? http://tilton-technology.com Cells? http://www.common-lisp.net/project/cells/ Cello? http://www.common-lisp.net/project/cello/ Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film Your Project Here! http://alu.cliki.net/Industry%20Application From tfb at OCF.Berkeley.EDU Sun May 23 23:30:06 2004 From: tfb at OCF.Berkeley.EDU (Thomas F. Burdick) Date: Sun, 23 May 2004 16:30:06 -0700 Subject: [cells-devel] Call for Cells Regression Test Suite Additions In-Reply-To: <40AB63F8.4010903@nyc.rr.com> References: <40AB63F8.4010903@nyc.rr.com> Message-ID: <16561.13310.206848.718531@famine.OCF.Berkeley.EDU> Kenny Tilton writes: > This is mostly for Thomas who is actually using a couple of features I > have added to Keep Other People Happy, but I thought the list would be > interested... Just a plug for lazy rules -- they're really nice when you're using any kind of IPC. Unnecessary network traffic and round trips to the database are bad bad, evil, and bad. > Anyway, it occurs to me the regression test does not include any > checking of either lazy cells or unbounditude handling. Speaking of > laziness, I probably will not do tests for those on my own, so if you > would like Cells II tested out before release for either of those please > send along some tests. It would be nice if they worked via cv-assert. > Note that in some places I also confirm that an error is produced on > deliberate no-nos. You might want to do some of that, too. I've been a little low on hacking time recently, and have been spending it on Unix IPC examples for comp.lang.lisp, and putting together a well made patch for Araneida (the efforts are related). RTs for unbound cells and laziness are next. In fact, I think a couple tests in the suite for the last app I wrote would be applicable.