"static_wrapper" imports in the FFI

Simon Marlow marlowsd at gmail.com
Tue Mar 16 18:22:43 EDT 2010

On 15/03/10 23:54, Iavor Diatchki wrote:
> Hi,
> I think that one may view a "static_wrapper" import as a pair of an
> export like the one you wrote and an import of the address of the
> exported function (this is useful because usually it is convenient to
> install the handler on the Haskell side).  Perhaps that's a better way
> to explain its meaning, rather then the long-winded example that I
> wrote. Thanks!
> In practice, the foreign export generates slightly less direct code,
> because the C code follows 2 indirections: first we enter the closure
> for "cbind", and then _that_ code enters the closure for the actual
> Haskell function.  Perhaps with sufficient optimization on the C side
> this can be avoided although I don't think that it happens at the
> moment.
> In terms of notation, I like the directness of the "static_wrapper"
> declaration (although not so much the "static_wrapper" name!) because
> it avoids duplication, thus reducing clutter and potential errors.

It seems hard to justify adding this to GHC, since it's really just 
syntactic convenience for a particular case.  Traditionally syntactic 
sugar for FFI declarations has been implemented in the preprocessing 
tools: c2hs and hsc2hs, whereas the FFI extension itself is purposefully 

So at the moment we're slightly inclined not to put it in - but feel 
free to make a compelling case.  Note that as an extension in its own 
right it would need its own flag, documentation etc.


> -Iavor
> On Mon, Mar 15, 2010 at 3:56 PM, Tyson Whitehead<twhitehead at gmail.com>  wrote:
>> On March 15, 2010 12:48:02 Iavor Diatchki wrote:
>>> I have implemented a small extension to the FFI which allows for
>>> "static_wrapper" imports.  These are a variation on "wrapper" imports
>>> that do not use run-time code generation.  This is important in
>>> security sensitive contexts because it avoids executable data.  While
>>> "static_wrapper" imports are less general then "wrapper" imports, they
>>> can be used to install Haskell handlers in many C libraries where
>>> callbacks have an extra "user-data" parameter (e.g., GTK signal
>>> handlers).
>> Hi Iavor,
>> Would not the following also do what you want
>>   foreign export ccall "haskellCIntCInt" \
>>    cbind :: CInt ->  StablePtr (CInt ->  IO CInt) ->  IO CInt
>>   cbind :: a ->  StablePtr (a->  IO b) ->  IO b
>>   cbind x f = deRefStablePtr f>>= (\f_ ->  f_ x)
>> On the C side you would then have something like
>>   register_callback(haskellCIntInt,<wrapped haskell closure>)
>> where<wrapped haskell closure>  would be a stable pointer of type StablePtr
>> (CInt ->  IO CInt) generated on the haskell side via
>>   newStablePtr<haskell closure>
>> and passed to the C code.
>> Cheers!  -Tyson
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

More information about the Glasgow-haskell-users mailing list