[Fwd: Re: [cells-devel] More newbie questions]

[Kenny Tilton]

-------- Original Message --------
Subject: 	Re: [cells-devel] More newbie questions
Date: 	Sun, 06 Mar 2005 15:55:29 -0500
From: 	Kenny Tilton <ktilton at nyc.rr.com>
To: 	Mike J. Bell <ckimyt at gmail.com>
References: 	<cfae84d805030507185b924b26 at mail.gmail.com> 
<4229F03F.2050100 at nyc.rr.com> <cfae84d8050306120043642e64 at mail.gmail.com>



Mike J. Bell wrote:

>I'm quoting a bunch of stuff, sorry so long, but I think it's all
>related...comments below.
>
>On Sat, 05 Mar 2005 12:45:35 -0500, Kenny Tilton <ktilton at nyc.rr.com> wrote:
>  
>
>>Mike J. Bell wrote:
>>    
>>
>>>5) Multi-method (?) calculations:  I've seen simple examples in the
>>>Cells docs that show a slot being dependent on another slot.  It looks
>>>like you install this computation in the "destination" slot, i.e. the
>>>one that's dependent.  What if you've got a situation where you have
>>>five slots, A B C D and E, that are parts of say three different
>>>objects, O1 O2 and O3.  There's one computation that needs A B C D and
>>>E, and ends up modifying slots F G H and I in objects O4 and O5.  Can
>>>it be done, making a single computation that depends on many slots in
>>>different instances that then updates slots in many instances?  Or do
>>>you need to decompose this computation into (complicated!) pieces to
>>>be installed in each of the destination slots (F G H and I)?
>>>
>>>      
>>>
>>You say complicated, I say "divide and conquer". Have you ever developed
>>a finite state machine, breaking some complex problem down into a
>>kazillion states? It seems painfully slow at first, until you realize
>>how effortlessly the approach deals with the overall computation, which
>>had you so confused that you resorted to using a finite state machine. :)
>>
>>Cells is all about exposing the semantics of a slot in the one formula
>>which determines the value of a slot. What you are describing is
>>"classic" imperative programming, where this point in the code decides
>>FGHI, another decides GH, another decides GHZ, etc etc. At which point
>>no one can really tell us the semantics of H.
>>
>>Now if you promise me that there is one and only one computation which
>>decides FGHI, what I do in cases like that is simply create a new slot
>>called FGHI (I wager the real name will be quite meaningful to anyone
>>reading your code) and then F, G, H, and I can have extremely simple rules:
>>
>>   :f (c? (get-f (^fghi)))
>>   :g (c? (get-g (^fghi)))
>>   ..etc...
>>
>>    
>>
>>> Can a
>>>change in one or more of A B C D and E cause a computation that
>>>updates C D F and G?  (I.e. C and D are both inputs *and* outputs of
>>>the calculation.  Note that self-cycling must be avoided!).
>>>
>>>      
>>>
>>Again, sounds like you are resisting "divide and conquer". <g> I have
>>been doing cells for about nine years now, and I have never had a
>>problem decomposing big computations into so many slots mediated by so
>>many cells. The cyclicity thing rarely materializes, but see my
>>discussion of scrollbars in an earlier reply for how I handle that
>>cyclic case.
>>
>>    
>>
>>>6) Multiple "owners" of responsibility, or aspect separation:  (this
>>>is related to #5 above)  What if you have a normal calculation that
>>>happens 99% of the time that changes slot A into slot B (B is
>>>dependent on A).  You write the formula into the slot code for B, and
>>>you're happy.  But then, because of some strange requirement or other
>>>complicated design issue, you realize that B also depends, every once
>>>in a while (say 1%), on C D and E.  But you don't want to stick this
>>>new computation and dependency code with the original code, because it
>>>will not only clutter reading, but also the complicated process may
>>>change in the future.
>>>
>>>      
>>>
>>You say "clutter", I say "completely specified". <g> What is wrong with:
>>
>>      (c? (if (one-chance-in-a-million self)
>>               (big-hairy-mess (^c) (^d) (e)))
>>               (nice-and-easy (^a))))
>>
>>And who cares if it changes in the future? Just maintain the formula,
>>which will always fully document the semantics of a slot. One of the
>>nice things about not using GOTOs is just /knowing/ without worrying
>>that any given point in the code is always reached via visible control flow.
>>    
>>
>
>I think these comments strike into the heart of the differences
>between Cells and what I'm using.  It seems to me they're both
>event-driven paradigms; Cells is declarative, and mine is imperative.
>
>I guess my biggest concern about using Cells at this point (and I
>think I'm going to have to just try it and see!) is scalability, from
>a design perspective.
>
>In the system I'm using right now, because the data and functions that
>operate on it are separate (and many to many), you get a really nice
>modularization of major aspects of an application.  For instance, I
>wrote a program that loads and displays audio waveform data visually. 
>The original code allowed integer multiples of zooming.  The zoom
>factor was represented by one of these pieces of data.  The drawing
>code listened for changes in this data in order to repaint the screen
>at the appropriate zoom level.  The GUI widget (slider) posted changes
>to this zoom factor.  This exemplifies the extreme separation of
>model, view and controller (as I'm sure Cells does as well).
>
>Now, the really nice thing about the system I'm using is that when a
>new requirement came along about zoom levels, I didn't have to touch a
>single bit of old code.  It went like this:  a ruler was added to the
>screen to show a timecode display with the waveform.  Because of
>strange "evenness" or regularity constraints on the design, the zoom
>level couldn't just be any old integer...it had to satisfy a
>divisibility property involving the sample rate of the audio.  This
>contraint was written as a new function that took the sample rate and
>the zoom level as inputs, and published (possibly) a new zoom level
>that was "correct."  The old code remained exactly the same, and the
>new code was added to the application, and everything just works.
>
>In the declarative model that I think Cells uses, I would have had to
>change code that's already written, tested, debugged, etc. in order to
>effect the change in requirements.
>
Not sure what code you are referring to. I would not have the slider set 
the zoom, I would give the zoom a rule which watched the slider value, 
which would just go from zero to one. When the new requirement came 
along I would simply have the zoom rule look at the slider /and/ the 
sample rate. Seems easy enough to me, and more self-documenting than the 
approach you described. If the zoom value is coming out wrong, I like 
knowing without doubt exactly where to look. Hell, in the inspector I 
can even look at the code, which for debugging purposes I store in 
symbolic form in the Cell for those cases where a slot gets different 
rules for different instances so often that it is painful to work out 
which rule applies to some instance I am debugging.

I am not saying I do not find constraint programming interesting or that 
it would not be fun to simply drop a new rule in the basket as a way of 
modifying a program. On the other hand, I have heard nothing but 
nightmares about what it is like to program with multi-way and partial 
constraints, so I have not been tempted to add anything like that to 
Cells (so far <g>).

>  Granted this is a simple example,
>picked for its ease of describing, but I've had this pattern occur
>quite a bit coding in the system I'm using...i.e. 95% of my
>application stands as is, with most changes just introducing new code
>which operates on existing defined data in the application.
>
>Please don't take any of my comments as negative criticism.
>
Not at all. We are both working the same very productive field, 
constraints of one kind or another, and we see the same benefits.

kt




-- 
Cells? Cello? Cells-Gtk?: http://www.common-lisp.net/project/cells/
Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film

"Doctor, I wrestled with reality for forty years, and I am happy to state that I finally won out over it." -- Elwood P. Dowd