
This is a real world example of a gui that I am having trouble conceptualizing in haskell. The problem is as follows: There is a list of object instances. Each object has a makeInstance function which displays an interface to an instance. Changes to the interface update the object and all interfaces. Changes to the object update all interfaces. An example of such an object would be an Int. The Int is interfaced by an spinbox. Another object could be an array. It would be represented by two spinboxes (index and value). Here is the c++ solution: class Object { public: virtual shared_ptr<Widget> make_interface()=0; private: signal onChange; public: void doOnChange( function<void> functionToDo ) //... }; class Int { private: int m_int; public: int getVal() { return m_int; } void setVal( int i) { m_int = i; onChange(); //Calls callbacks } virtual shared_ptr<Widget> make_interface() { shared_ptr< SpinBox > spinbox = new Spinbox(); spinbox.set_getter( getVal ); spinbox.set_setter( setVal ); doOnChange( bind( &Spinbox, SpinBox::refresh ) ); } }; What would a haskell solution look like? In my opinion this functionality would be very desirable if not required. David J. Sankel

On Tue, 1 Apr 2003 17:21:33 -0800 (PST)
David Sankel
What would a haskell solution look like? In my opinion this functionality would be very desirable if not required.
If I got you, that problem can be solved in many ways; one of these is the already mentioned "linking" of state variables. Other solutions involve state handling via functions that can be redefinded by the user. Vincenzo

--- David Sankel
What would a haskell solution look like? In my opinion this functionality would be very desirable if not required.
Here is one solution using normal MVars. It is IMHO uglier than the c++ version. I think creating an extention of MVars to allow callbacks on change and syncronized variables would be very nice with this example problem. I would also suggest removing the empty MVar status.

On Thu, 3 Apr 2003 08:53:54 -0800 (PST)
David Sankel
I would also suggest removing the empty MVar status.
MVars are for synchronization. An MVar is a container for a shared resource. If the MVar is empty, then the resource is not available. It's the more elegant kind of locking that I've ever seen. If only there was the possiblity to wait for more than one mvar, and a linear ordering etc :) V. -- Teatri vuoti e inutili potrebbero affollarsi se tu ti proponessi di recitare te [CCCP]

On Thu, Apr 03, 2003 at 08:53:54AM -0800, David Sankel wrote:
--- David Sankel
wrote: What would a haskell solution look like? In my opinion this functionality would be very desirable if not required.
Here is one solution using normal MVars. It is IMHO uglier than the c++ version. I think creating an extention of MVars to allow callbacks on change and syncronized variables would be very nice with this example problem. I would also suggest removing the empty MVar status. Your solution might be dirty but it works. It might be cleaner if we had state variables which trigger a callback when they change (I guess this functionlity is close to Manuel's Port library). But in case we need to synchronize three entities we might run into problems with augmented state variables. But maybe it's always sufficient...
I wouldn't claim that features like linking state variables and having callbacks on changing these is completely high level, I still think it is beyond the *needs* of an initial CGA and, thus, shouldn't be implemented right now. Two observations: a) It would be nice to have useful abstractions like linkable state variables, state variables with callbacks on change, streams, filters, etc. b) At this early stage we can only guess how useful/restrictive these features are in practice. If these additions have to be desinged in from the start (i.e. are not orthogonal to the CGA), then we even risk making high level APIs on top of CGA impossible. I would like to start with something simple and verify in practice which concepts in a) are useful. Otherwise we run into the risk of cluttering the API with unused functionality. I don't mind breaking the CGA between version 1.0 and 2.0, but I don't want to go to version 2.0 right away since it takes much longer and it's harder to get it right. Axel.
participants (3)
-
Axel Simon
-
David Sankel
-
Vincenzo Ciancia