[cells-devel] Optimized away/dying rules

[Ken Tilton]

First, just a point of information: do I understand correctly that the
original example below uses an assoc instead of your store just to simplify
the problem and highlight the key issue?
I am guessing yes, so I will charge ahead with my thoughts: basically you
need to make the lookup itself establish a dependency. I had assumed that
this what you had done when you said you had created a cells-aware store. I
was guessing that behind the scenes there was a second hashtable with the
same key but a value that was a list of the cells that had looked it up. (Or
you could try stuffing the thing stored with a list of asking cells in the
one hash-value.) That would have gotten you into c-link, c-unlink, and other
good stuff.

And then you are done. Everything (including sensible optimization) just
flows from that.

Sorry if I am all wet or if not for not examining your code earlier. I'd
look now but jet lag beckons. I'll try later or just let me know if this is
making sense.

cheers, kenny

ps. I did not stare too hard either at your deferred optimizarion or
something idea because I saw this other more standard approach to the
problem, but again if it turns out I missed something I'll stare at that too
when I recover a little. k

pps. Interesting idea: if things never go away you can lose the dependency
of the seeker on the store once the sought key appears. Not sure how to
express that, unless we tackle the not-to-be issue by doing something I have
toyed with before (and might even still be out there): a rule that says when
an instance dies. In the case where that is a hardcoded nil or a rule that
produced nil and then got optimized away, the cells-store could drop the
dependency from its side after propagating to the asker. k



On Wed, Apr 16, 2008 at 11:26 AM, Peter Hildebrandt <
peter.hildebrandt at gmail.com> wrote:

> While working on the hash-table lookup for md-names (as an alternative
> to fm-other) I came across an interesting phenomenon: Some rules die,
> others don't.  Following the XP idea for RFEs, I'll try to present a
> test case:
>
> (defpackage :c-test (:use :cl :cells :utils-kt))
> (in-package :c-test)
>
> (defparameter *hash* (make-hash-table))
> (defun val (name) (bwhen (obj (gethash name *hash*))
>                            (value obj)))
>
> (defparameter *m1* (make-instance 'model :value (c? (bif (v (val
> :foo)) (1+ v) 'nothing))))
> (assert (eql (value *m1*) 'nothing))
>
> (setf (gethash :foo *hash*) (make-instance 'model :value (c-in nil)))
>
> (defparameter *m2* (make-instance 'model :value (c? (bif (v (val
> :foo)) (1+ v) 'nothing))))
>
> (assert (eql (value *m1*) 'nothing))
> (assert (eql (value *m2*) 'nothing))
>
> (setf (value (gethash :foo *hash*)) 42)
> (assert (eql (value *m1*) 43))  ;;; #### FAILS ####
> (assert (eql (value *m2*) 43))  ;;; ok
>
> (setf (value (gethash :foo *hash*)) 17)
> (assert (eql (value *m1*) 18))  ;;; #### FAILS ####
> (assert (eql (value *m2*) 18))  ;;; ok
>
> ;;; or with a list
>
> (defparameter *list* nil)
> (defun valb (name) (bwhen (obj (assocd name *list*))
>                            (value obj)))
> (defparameter *m1b* (make-instance 'model :value (c? (bif (v (valb
> :foo)) (1+ v) 'nothing))))
>
> (assert (eql (value *m1b*) 'nothing))
>
> (push (cons :foo (make-instance 'model :value (c-in nil))) *list*)
>
> (defparameter *m2b* (make-instance 'model :value (c? (bif (v (valb
> :foo)) (1+ v) 'nothing))))
>
> (assert (eql (value *m1b*) 'nothing))
> (assert (eql (value *m2b*) 'nothing))
>
> (setf (value (assocd :foo *list*)) 17)
> (assert (eql (value *m1b*) 18))  ;;; #### FAILS ####
> (assert (eql (value *m2b*) 18))  ;;; ok
>
> (setf (value (assocd :foo *list*)) 42)
> (assert (eql (value *m1b*) 43))  ;;; #### FAILS ####
> (assert (eql (value *m2b*) 43))  ;;; ok
>
> --------
>
> An interesting indicator might be that the first call to (value *m1*)
> returns two values, 'nothing and nil -- does that mean that cells
> somehow realizes there that this cell can be optimized out?
>
> And -- more importantly -- how can I tell cells not to optimize away
> the ruled cell in *m1*/*m1b*?
>
> Thanks,
> Peter
> _______________________________________________
> cells-devel site list
> cells-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/cells-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/cells-devel/attachments/20080418/864d55a7/attachment.html>