Well, similar ideas have been brought up before, and I'm a bit sceptical: *) Why should we introduce a feature at the language level for solving a problem that is already solved by MVars? You can write your own combinators to reduce the hassle of using MVars to a minimum.
Firstly, thanks for your answer: I'm re-writting a Haskell-Maple library from Hans Wolfgang Loidl, basically adopting Haskell Posix Libraries and re-arranging concurrency issues around a Posix Pipe. I cannot send a URL since the code is a bit "unreadable", but it works... * From Haskell-Sequential, you don't neeed Mvars, since there are not forkIO'ds threads. * From a Haskell-Concurrent point of view, this is just to free the final Maple-Eden library user to consider concurrency uses, as the final signature should be: mapleEval :: String -> [MapleObject] -> MapleObject instead of mapleEval :: Mvar -> String -> [MapleObject] -> MapleObject However, this is not key... Programmer could make the effort for that. * The key problem arises now: We are programming on a Haskell-dialect parallel language, Eden, whose implementation extends that of Gph. There you have a Distributed Memory Model, each process ( process= set of "Concurrent threads" inside a processor-element) has its own heap,stack... Hence, every locally process has its own Mvar-state, and cannot be shared with other process-threads... It would have only sense on local heap, but you are not garanteed to run your process locally ( rather it will be remote ). That is because we need the "external context" monitor. Yes, we are forcing the language, I know... After all : import Concurrent newEmptyMVar :: IO(Mvar a) foreign import cgetMonitorMvar :: IO(Mvar a) are "safely" close under a monad , aren't they (*)? (*) Strictly speaking, we are storing/grabing (StablePtr a) to avoid the effect of the Garbage Collector
*) Why would we want all external calls to be serialized? In most circumstances, I'd like more granularity than that.
Yes, I agree with you,but just to get the effect of a "monitor", on a mutex region. Of course, it is not for large computations, just a little while
What exactly do you have in mind?
Cheers,
Also you.