Hi,

I've also observed that in the final lowered STG the State# is always passed to effectful primops and FFI calls, but the returning new State# is removed from the result type. The State# has VoidRep representation in in cmm, so no register gets allocated for it and eventually the State# function argument is compiled to nothing in the machine code. i.e. the compilation steps for the code above is:
foreign import ccall "math.h sin" sin :: CDouble -> CDouble
  1.  Initial STG type is: CDouble -> State# RealWorld -> (# State# RealWorld, CDouble #)
  2.  Lowered STG type is: CDouble -> State# RealWorld -> (# CDouble #)
  3.  FFI C function should be: double sin(double x);
Regards,
Csaba

On Mon, Oct 28, 2019 at 10:59 AM Christopher Done <chrisdone@gmail.com> wrote:

Hi all,

I tried compiling this file:

{-# LANGUAGE NoImplicitPrelude #-}
-- | Demonstrate various use of the FFI.
module Foreign where
import Foreign.C
foreign import ccall "math.h sin" sin :: CDouble -> CDouble
it :: CDouble
it = sin 1

And I’ve noticed that the annotated type given for this foreign op in Core, is (# State# RealWorld, CDouble #), whereas I would have expected e.g. CDouble.

Meanwhile, the foreign op call is passed a RealWorld argument.

Additionally, code that consumes the result of this foreign call expects a (# CDouble #) as a return value.

So there are some assumptions I put in my interpreter to test this FFI call out:

  1. Despite claiming to return the real world in a tuple, it actually should just return an unboxed tuple of the value.
  2. It should ignore the RealWorld argument entirely.

I assume, if I were to lift this function into returning IO, that I should indeed return the RealWorld argument given. So the lesson is:

All FFI functions accept a RealWorld, and may return a 2-tuple of State# RealWorld if it’s impure, else it’ll return a 1-tuple of the value. Correct?

Can someone confirm that my observations are right? Also, if so, is there somewhere I can read more about this?

Cheers

Chris

_______________________________________________
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs