Well, I promise this is the last feature request for state handling. I want... linked variables! For example a function link :: (a -> b) -> (b -> a) -> Var a -> Var b -> IO () when one writes to one variabile, the other gets written and vice-versa. This is not as easy as it seems (see the Ports library for issues), but can be done in various ways. It's useful when, for example, you want a scrollbar that control a numeric, user-writable textbox. You really want the two values to be synchronized! Also, this is useful for easy persistence of attributes. I am not sure the issue is generally solvable with filters only, like locking, but I guess so. Maybe it needs the ability to get any value that is *actually* written in the state, after all the filters have been processed. However, since it's clear that this state handling problem is longer to solve than I expected, but it's also clear that some of the problems that could arise needs to be handled now, or they will cause trouble forever (think about how would you implement filters if you had not them) I see three possible ways to keep on working: 1. Decide what of all the features that have been mentioned are really necessary, and identify primitive and derived features among those, then implement the thing. 2. Decide a minimal set of features (for example: create, get, set) that a "variable" needs to have, and just be prepared to extend that interface. This allows people that are not interested in subtle state handling techniques (wich are more high-level than mid-level) to start working on the widgets. 3. Decide the same minimal set of features, wich are the only one used in the construction of the base widgets, and allow the functions to be changed like other attributes. For example, we say that the features that are necessary to implement widgets are create, get and set. Then we allow the programmer to pass its own functions to a button, and the button will use these three functions to create, get and set its attributes. This allows to add e.g. filtering capabilities to the existing library in a second moment, and be sure that any other library that uses the get/set interface also gets "filtered". Note that combo of 1 and 2, and of 1 and 3 are possible, and if we choose 1, we are really getting "extended 2". If I haven't been clear, just ask; I would like to hear what you all think about this. Vincenzo