Possible runtime overhead of wrapping the IO monad?

[Simon Peyton-Jones]

| -----Original Message-----
| From: glasgow-haskell-users-bounces at haskell.org
[mailto:glasgow-haskell-users-
| bounces at haskell.org] On Behalf Of Brian Hulley
| Sent: 30 March 2006 13:14
| To: John Meacham; glasgow-haskell-users at haskell.org
| Subject: Re: Possible runtime overhead of wrapping the IO monad?
| 
| 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, ...

GHC does unwrap newtype result types, as in

	foreign import foo :: Int -> IO Boogle
	newtype Boogle = B Int

which is what the manual meant.  I'd never thought of newtyping the IO
monad itself.  Why are you doing that, incidentally?

I guess it wouldn't be too hard to unwrap the monad type too.  If it's
important to you, please submit a feature request.

Thanks

Simon