Possible runtime overhead of wrapping the IO monad?

Brian Hulley brianh at metamilk.com
Thu Mar 30 07:13:51 EST 2006

John Meacham wrote:
> On Thu, Mar 30, 2006 at 03:50:06AM +0100, Brian Hulley wrote:
>> where the intention is that the callback will take the width and
>> height of the window and return a RenderM action, the problem is
>> that because the FFI does not allow RenderM to appear in a foreign
>> type.
> it should, the types in foreign declarations should "see through"
> newtypes.

Unfortunately GHC does not seem to support this:

   foreign import ccall duma_clear :: Word.Word32 -> RenderM ()

       Unacceptable result type in foreign declaration: RenderM ()
       When checking declaration:
       foreign import ccall safe "static  &duma_clear"
            duma_clear :: GHC.Word.Word32 -> RenderM ()

even though the FFI spec agrees with you (Section 3.2):

     The argument types ati produced by fatype must be
     marshallable foreign types; that is, each ati is either (1)
     a basic foreign type or (2) a type synonym or renamed
     datatype of a marshallable foreign type. Moreover, the
     result type rt produced by frtype must be a
     marshallable foreign result type; that is,
     it is either a marshallable foreign type, ...

Thus leading to all the messy fiddling about I have to do to use RenderM 
instead of IO in my imported functions and callbacks.

A tool like greencard may solve some of these problems but the problem I 
would then have is how to incorporate it in my very flaky development 
environment (I'm just using the plain text editor in Visual C++ with a 
shortcut bound to a batch file which calls ghc so the build process is all 
held together by bits of string and sellotape therefore I don't want to 
complicate it further if at all possible...)

By the way, I think I may have been wrong about GHC not optimizing the call 
to dropRenderM out of the onRender function in my last post, because when I 
look at the output using -dddump-cmm (instead of -simpl) dropRenderM is not 
mentioned in the code for onRender (although I'm not an expert at reading 
cmm output either and it is mentioned in some other places....)

Regards, Brian.

More information about the Glasgow-haskell-users mailing list