If you are already using one-way dataflow constraints, you weren't exactly the target audience for my writeup, which was trying to introduce this body of work to devs who may only be familiar with the pale imitations. I am a bit surprised that you are careful to avoid cycles, even the one-way solvers I mention handle those.
I also think that the one-way solvers are the most immediately useful. On the other hand, the linguistic support needed for a pluggable one-way solver seems very similar to that needed for other solvers, and yes, they can be quite useful in more general circumstances. After all there is a whole field and several companies that do this sort of thing commercially.
fair enough that maybe i'm not in the target audience. and perhaps i'm too stuck in my own head, writing iOS apps, where i can't imagine general constraint solvers being used to solve a software-design problem (as opposed to an algorithmic problem, where it certainly does make sense). i am genuinely curious - are general constraint solvers useful as a software-design pattern?
are one-way dataflow constraints really any different from the observer pattern? i avoid cycles exactly because i implement it myself, and don't even have a solver, per se. even KVO seems not to handle cycles. and when e.g. i am using auto-layout in IB, even then i am careful to avoid over-constrainedness, even though the solver can settle on a "solution."
I also think that the one-way solvers are the most immediately useful. On the other hand, the linguistic support needed for a pluggable one-way solver seems very similar to that needed for other solvers, and yes, they can be quite useful in more general circumstances. After all there is a whole field and several companies that do this sort of thing commercially.