
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.