FFI: c/c++ struct on stack as an argument or return value

[Carter Schonwald]

indeed, its very very easy to do storable instances that correspond to the
struct type you want,

the ``with`` function in
http://hackage.haskell.org/package/base-4.6.0.1/docs/Foreign-Marshal-Utils.htmlforeigh.marshal.utils
actually gets you most of the way there!




On Sat, Mar 15, 2014 at 12:00 AM, Manuel M T Chakravarty <
chak at cse.unsw.edu.au> wrote:

> Yuras,
>
> I’m not convinced that the compiler is the right place for this kind of
> functionality. In fact, when we designed the Haskell FFI, we explicit
> decided against what you propose. There are a few reasons for this.
>
> Firstly, compilers are complex beasts, and secondly, it takes a long time
> until a change in the compiler goes into production. Hence, as a general
> rule, it is advisable to move complexity from the compiler into libraries
> as this reduces compiler complexity. Libraries are less complex and changes
> can be rolled out much more quickly (it’s essentially a Hackage upload
> versus waiting for the next GHC and Haskell Platform release).
>
> Thirdly, we have got the Haskell standard for a reason and modifying the
> compiler implies a language extension.
>
> The design goal for the Haskell FFI was to provide the absolute minimum as
> part of the language and compiler, and to layer additional conveniences on
> top of that in the form of libraries and tools.
>
> Have you considered the library or tool route?
>
> Manuel
>
> Yuras Shumovich <shumovichy at gmail.com>:
> > Hi,
> >
> > Right now ghc's FFI doesn't support c/c++ structures.
> >
> > Whenever we have foreign function that accepts or returns struct by
> > value, we have to create wrapper that accepts or returns pointer to
> > struct. It is inconvenient, but actually not a big deal.
> >
> > But there is no easy workaround when you want to export haskell function
> > to use it with c/c++ API that requires structures to be passed by value
> > (Usually it is a callback in c/c++ API. You can't change it's signature,
> > and if it doesn't provide some kind of "void* userdata", then you are
> > stuck.)
> >
> > I'm interested in fixing that. I'm going to start with 'foreign import
> > "wrapper" ...' stuff.
> >
> > Calling conventions for passing c/c++ structures by value are pretty
> > tricky and platform/compiler specific. So initially I'll use libffi for
> > that (it will work when USE_LIBFFI_FOR_ADJUSTORS is defined, see
> > rts/Adjustor.c). It will allow me to explore design space without
> > bothering about low level implementation details. Later it could be
> > implemented for native (non-libffi) adjustors.
> >
> > Is anybody interested it that? I appreciate any comments/ideas.
> >
> > Right now I don't have clear design. It would be nice to support plain
> > haskell data types that are 1) not recursive, 2) has one constructor and
> > 3) contains only c/c++ types. But it doesn't work with c/c++ unions. Any
> > ideas are welcome.
> >
> > An example how to use libffi with structures:
> > http://www.atmark-techno.com/~yashi/libffi.html#Structures
> >
> > Thanks,
> > Yuras
> >
> >
> > _______________________________________________
> > ghc-devs mailing list
> > ghc-devs at haskell.org
> > http://www.haskell.org/mailman/listinfo/ghc-devs
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140315/fa7cd0ac/attachment-0001.html>