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 < [email protected]> 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 < > [email protected]> 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 <[email protected]>: >> > 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 >> > [email protected] >> > http://www.haskell.org/mailman/listinfo/ghc-devs >> >> _______________________________________________ >> ghc-devs mailing list >> [email protected] >> http://www.haskell.org/mailman/listinfo/ghc-devs >> > > > _______________________________________________ > ghc-devs mailing list > [email protected] > http://www.haskell.org/mailman/listinfo/ghc-devs > >
_______________________________________________ ghc-devs mailing list [email protected] http://www.haskell.org/mailman/listinfo/ghc-devs
