Sure. I imagine a good structure would be something like this (simplified, but gives the right idea):

```
enum Formula {
Value(i32),
Add(Rc<Cell>, Rc<Cell>),
}
struct Cell {
formula: Mutable<Rc<Formula>>,
}
impl Cell {
fn value(&self) -> impl Signal<Item = i32> {
self.formula.signal_cloned().switch(|formula| {
match formula {
Formula::Value(x) => Box::new(always(x)),
Formula::Add(x, y) => Box::new(map_ref! {
let x = x.value(),
let y = y.value() =>
*x + *y
})
}
})
}
}
```

(And similarly for other operations, like multiplication, etc.)

By setting things up this way, you create a dynamically changing graph which will automatically update whenever a cell’s value changes, *or* when a cell’s formula changes.

Everything is handled automatically by the Signals system, so you only need to worry about updating the `Mutable`

whenever the user types into the cell.

And since `Formula`

is recursive (it can refer to other `Cell`

s), this means the graph will efficiently update no matter how deep the dependencies are.

The allocations for the `Rc`

and `Box`

are probably necessary, in order to support the fact that the graph can dynamically change.

With some tricks, you might be able to remove the allocations, but I’m not sure if that’s worth it.

I’m happy to talk more about this in a private message (or in an issue on the futures-signals repo).