[cells-devel] Re: Cells: How to later set a formula for a cell ?

[Ken Tilton]

Frank Goenninger wrote:

>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA512
>
>Am 03.04.2006 um 22:10 schrieb Ken Tilton:
>
>  
>
>>Goenninger, Frank wrote:
>>
>>    
>>
>>>Hi Kenny,
>>>
>>>currently heavily playing wit Celtk...
>>>
>>>I have up to now only set a cell's formula by using directly  
>>>(c? ...)  with default-initargs. Now I am stopped cold by the fact  
>>>that I have  to be able to set the formula by some setf form. How  
>>>to do that in a  conforming way ?
>>>      
>>>
>>Download KR from the Garnet system, they have a million backdoors  
>>like that. :)
>>    
>>
>
>Don't get me tempted... You risk loosing a real Cells adict ;-)
>
>  
>
>>What's the big picture on this? Maybe there is a way to do it  
>>without an alley-oop.
>>    
>>
>
>I certainly hope there is!
>
>The big picture - and I begin wondering if phrased my original  
>question as misleading  - is that I have laaarge code fragments being  
>complex rules for a cell formula. I want to stick that in a separate  
>function in order to code in a more readable way ?!
>
First of all, a trick I use all the time because I never like to look at 
too much code at once:

(make-instance 'thing :myslot (big-long-thing-myslot-rule-1)) ;; observe 
that there is no c? here

(defun big-long-thing-myslot-rule-1 ()
   (c? <big long rule>)) ;; here is the c?

Second of all, do not forget that Cells work by dynamic not lexical 
reference, so:

> When trying to  
>achieve this I figured that c? does not much but I simply found that  
>I need the context of the cell slot to stick some rule to it.
>  
>
I doubt it. :) Are you talking about the (^myslot) forms not working? 
That just captures the lexical variable self. I use ^macros all the 
time, because I pretend I am doing Smalltalk and always call the chief 
instance to a function "self". So I get to use ^macros all over the 
place, in a rule or not.

If you are talking about .cache, and do not want to pass it down the 
call tree, we will have to start exposing Cell internals.

oh, I forgot to say: just do what you always do when a function gets too 
big. Split it up. Again, any /dynamic/ reference will establish a 
dependency, ie, the reference does not need to appear in the code of the 
rule (that would be lexical). So divide big-long-rule up into a driver 
and a bunch of helper functions as you would do normally and it will all 
Just Work.

>Second use case:
>
>Imagine I have a knowledge base (using inference) that produces cell  
>formulae based on facts and rules I have put into the knowledge base.  
>So, I have to be able to act on lists of structure ( cell-id formula- 
>form ) and stick those new formula-forms into the given cells with id  
>cell-id.
>  
>
I have thought about such a thing. I have not actually had to do it (so 
maybe reality would change my approach) but I would simply keep the two 
beasts apart, Cells and KB:

   (make-instance 'thing :rule-driven-slot (c? kb-apply 
(kb-compute-formula <fact-1> <fact-s> <circumstance-3>))

Observe that as the parameters to kb-compute-formula change you will get 
a new rule as well as new computation. The downside is that, as the 
slots accessed only during kb-apply change, you will unnecessarily 
recompute the rule to be kb-applied. So:

  ...:rule-to-kb-apply (c? (kb-compute-formula f1 f2 c3))
     :rule-driven-slot (c? (kb-apply (^rule-to-kb-apply))

ie, Let Cells do its primitive little dataflow thing and let the fancy 
KR/KB system do its clever machine thinking and do not bother them with 
each other's burden.

ken

-------------- next part --------------
A non-text attachment was scrubbed...
Name: kentilton.vcf
Type: text/x-vcard
Size: 171 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/cells-devel/attachments/20060403/503aba7a/attachment.vcf>