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 <ekm...@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.schonw...@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 < >> c...@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 <shumovi...@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@haskell.org >>> > http://www.haskell.org/mailman/listinfo/ghc-devs >>> >>> _______________________________________________ >>> ghc-devs mailing list >>> ghc-devs@haskell.org >>> http://www.haskell.org/mailman/listinfo/ghc-devs >>> >> >> >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs@haskell.org >> http://www.haskell.org/mailman/listinfo/ghc-devs >> >> >
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
