A critic of Guido's blog on Python's lambda

[Thomas F. Burdick]

Ken Tilton <kentilton at gmail.com> 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.