...

the point being: the FFI says something about how to integrate foreign and Haskell memory management; should it also say something about threadability of foreign code (wrt to scheduling, and wrt thread-safety)? If Haskell' includes concurrency then of course it must say something about the behaviour of foreign calls with respect to concurrency (if that's what you mean by "threadability"). Is that what you're asking?

yes. I'm all for Haskell' having both ffi and concurrency, but that means that the feature interactions have to be investigated. I know you made a start on that, so I was just pointing out some further corners that may need looking into: - if foreign code is used in Haskell' scheduling, what properties of the foreign code need to be specified, how does long-running foreign code interact with the scheduler, and are the current annotations sufficient for all that? - if Haskell' code involving concurrency is foreign exported, what does that mean? does it work out of the box, or what are the limitations?

...

so if we take that hypothetical example of foreign exporting GHC's concurrency support, can we assume that the (IO a)s implemented in foreign code will be given their own OS thread when using that concurrency library? all of them, or only the non-atomic ones? I'm sorry, I completely fail to see what you're getting at with this line of discussion. Could you say in more detail how you expect to provide access to concurrency via the FFI? And what the point of it is? (it's not obvious how to foreign export forkIO, for example).

I was looking for a practical example involving concurrency and ffi in such a way as to expose some of the questions that need to be answered. you're mentioning forkIO, so that's an example of such questions: why shouldn't we be able to foreign export that? it's just a bit of Haskell functionality with a library API, isn't it? the example is practical, yet rather complex: Haskell foreign exporting concurrency, foreign code that uses the Haskell concurrency library api also being used as callbacks in things like forkIO. will the combination of concurrency and ffi envisioned for Haskell' be up to that kind of thing or not? without looking at the current specs, just naively seeing the libraries Control.Concurrent and Control.Concurrent.MVar, and knowing that there is such a thing as foreign export, I would expect to be able to apply the latter to the former. the MVars would hold C data not interpreted on the Haskell side (just stored and passed around), and the C code would appear as IO a on the Haskell side, as far as forkIO is concerned. I admit this is a naive view, and I particularly avoided checking the specs first, but why should Haskell' programmers not expect this to work, if the language has both concurrency and ffi? cheers, claus