Ken Tilton <[EMAIL PROTECTED]> writes: > David C. Ullrich wrote: > > > But duh, if that's how things are then we can't have transitive > > dependencies working out right; surely we > > want to be able to have B depend on A and then C > > depend on B... > > (And also if A and B are allowed to depend on each > > other then the programmer has to ensure that the > > two rules are inverses of each other, which seems > > like a bad constraint in general, something non-trivial > > that the programmer has to get right.) > > Right, when I considered multi-way dependencies I realized I would > have to figure out some new syntax to declare in one place the rules > for two slots, and that would be weird because in Cells it is the > instance that gets a rule at make-instance time, so i would really > have to have some new make-instance-pair capability. Talk about a > slippery slope. IMO, the big constraints research program kicked off > by Steele's thesis withered into a niche technology because they > sniffed at the "trivial" spreadsheet model of linear dataflow and > tried to do partial and multi-way dependencies. I call it "a bridge > too far", and in my experience of Cells (ten years of pretty intense > use), guess what?, all we need as developers is one-way, linear, > fully-specified dependencies.
It may also be that the bridge too far was in trying to do big, multi-way constraints in a general-purpose manner. Cells provides you with the basics, and you can build a special-purpose multi-way system on top of it, much like you can use it as a toolkit for doing KR. -- http://mail.python.org/mailman/listinfo/python-list
