rpgoldman@real-time.com wrote:
"Kenny" == Kenny Tilton ktilton@nyc.rr.com writes:
Kenny> Mike J. Bell wrote:
[...snip...]
Kenny> Cells have always grown in response to application Kenny> requirements, so if someone comes up with a good example I Kenny> will gladly look at implementing cycles in Cells. The Kenny> question is, how can a = f(b) and b=f(a) ever be computed? Kenny> In your example, there is no real cycle, because you are Kenny> saying: "dollars is a function of yen /when changes/, and Kenny> yen is a function of dollar /when dollar changes/." Only Kenny> one can be changing at a time, so there is no cycle as the Kenny> problem is conceived.
Kenny> But how is an instance initialized? I can supply conversion Kenny> rules for dollar-balance and yen-balance, but how do I get Kenny> the intial balance in there? I would need to specify a Kenny> starting value, but for which one? Both? What if I specify Kenny> 1 for both? That conversion would be wrong, the dollar is Kenny> (for now) worth more than 1 yen.
Kenny> Conceivably the answer is to let the programmer worry about Kenny> it. I could specify a value (and the conversion rule) for Kenny> dollar-balance and specify "unbound" and a rule for all Kenny> other currencies. Then if the others get accessed, the Kenny> system just calculates as usual. If all values are unbound Kenny> a runtime error results. If the programmer specifies Kenny> inconsistent initial values they get a wrong result (which Kenny> we might be able to detect at some point of runtime) until Kenny> some SETF perturbs the model and the formulas kick in to Kenny> make things consistent.
Kenny> Thoughts on this?
IIRC, Garnet's KR has a mechanism (one might call it "a cheap hack") to solve the problem of cyclic dependencies, which was to allow you to "plonk" an initial value into a slot that would be used to kick the whole mess off.
Yes. I was frankly horrified by all the backdoor hacks KR allowed. I must be getting old and stodgy.
:)
kenny