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
