Hey Kenny, I did a lot of thinking about what you said about declarative vs. imperative. I'm not sure what's the right terminology, but I did finally see the light.
We've had problems in applications written in our framework when there are multiple producers of one datum. In a lot of cases (benign and simple), it's been OK. However, as soon as things get bigger, we put a repeating pattern into our designs where a single controller function will act as a gatekeeper, reading from multiple channels of data, and forming the single producer for the difficult datum in the previously intractable design.
I've thought about it quite a bit, and I've proved to myself that this is equivalent to your declarative model, even if there are some slight structural differences*. So, in order for me to get from where I am to where Cells is, all I need to do is instead of waiting for the multiple producers issue to get out of hand and uncontrollable...just nip it in the bud and don't allow it to begin with. Then every piece of data has only one producer.
Thanks again for talking with me about it!
Mike
* Speaking of structure, question for you. Let's say you're declaring a slot to be a function of a couple other slots in Cells. How do you know they exist? I.e., where do you find your objects? Do you have like a database somewhere (hash of name->object or the like) that you lookup to find things? Are they all passed in at construction time? (I would imagine this wouldn't scale well at all). Is there some other scoping mechanism?
I'm not sure if Cells has any builtin support for finding the other objects/slots that participate in Cells, or if you roll your own per application...but I'd love to hear about how you solve it when *you* write code.