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

[Carter Schonwald]

I'm not opposing that, in fact, theres a GHC ticket discussing some stuff
related to this (related to complex numbers).

i think the crux of Manuel's point is mainly that any good proposal has to
at least give a roadmap to support on all the various platforms etc etc


On Sat, Mar 15, 2014 at 12:33 AM, Edward Kmett <ekmett at gmail.com> wrote:

> I don't care enough to fight and try to win the battle, but I just want to
> point out that Storable structs are far more brittle and platform dependent
> than borrowing the already correct platform logic for struct passing from
> libffi.
>
> I do think the existing FFI extension made the right call under the 32 bit
> ABIs that were in use at the time it was defined. That said, with 64-bit
> ABIs saying that 2 32-bit ints should be passed in a single 64 bit
> register, you wind up with large chunks of third party APIs we just can't
> call out to directly any more, requiring many one-off manual C shims.
>
> -Edward
>
>
>
>
> On Sat, Mar 15, 2014 at 12:17 AM, Carter Schonwald <
> carter.schonwald at gmail.com> wrote:
>
>> 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
>>>
>>
>>
>> _______________________________________________
>> 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/80a92487/attachment.html>