Foreign Function Interface (FFI)

[Rafael Martinez Torres]

> 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.