base package (Was: GHC 7.8 release?)
marlowsd at gmail.com
Fri Feb 15 15:37:23 CET 2013
On 15/02/13 09:36, Simon Peyton-Jones wrote:
> | > Doesn't the FFI pull in some part of the I/O layer, though? In
> | > particular threaded programs are going to end up using forkOS?
> | Another good reason to try to have a pure ground library.
> Remember that we have UNSAFE ffi calls and SAFE ones.
> The SAFE ones may block, cause GC etc. They involve a lot of jiggery pokery and I would not be surprised if that affected the I/O manager.
> But UNSAFE ones are, by design, no more than "fat machine instructions" that are implemented by taking an out-of-line call. They should not block. They should not cause GC. Nothing. Think of 'sin' and 'cos' for example.
> Fingerprinting is a classic example, I would have thought.
> So my guess is that it should not be hard to allow UNSAFE ffi calls in the core (non-IO-ish) bits, leaving SAFE calls for higher up the stack.
Actually as far as the Haskell-level API goes, there's no difference
between safe and unsafe FFI calls, the difference is all in the codegen.
I don't think safe calls cause any more difficulties for splitting up
More information about the Glasgow-haskell-users