>From my experience, these things are needed to get solid (i.e. not flaky software) results. This is not what normal Haskell bindings look like though:
1. Create an interface over the Haskell RTS if you are going to use any of it from C++, and use dependency injection to choose between mock and real implementations. 2. Create a mock implementation of the Haskell side if it is accessed from C++. 3. Create comprehensive C++ only tests (using mock Haskell) that runs cleanly through valgrind. 4. Create as small an interface between C++ and Haskell as possible. 5. If you have a wide API that has little performance implications between Haskell and C++, consider not using the FFI directly, but a higher-level abstraction such as protocol buffers for this part of your API. Alexander On Thu, Jan 31, 2013 at 9:53 AM, Casey Basichis <caseybasic...@gmail.com>wrote: > Hi Ertugrul, > > Thank you for the detailed reply. From what you wrote, partial FFI still > seems like the way to go. > > Unfortunately Ogre isn't the only large library I'm using, so "difficult" > several times over sounds like a good way to handicap the project early on. > > I'm perfectly happy to use Haskell for the strengths that will most > benefit my project. I can always go back and try to bring the C++ specific > parts into the fold once a prototype is up and running. > > As it seems there is a great deal of c/c++ to do either way, I would > really appreciate so thoughts towards my original question. > > What practices in C++ are preferred by Haskell users, in the know, for the > parts of the app that will not be pure Haskell? > > Should I be looking to avoid OOP? Dependency Injection? I wont reiterate > all the facets of the first post, but it would help me immensely to zero in > on a few patterns and strategies that can minimized the damage I inflict in > c++ land. > > Thanks, > Casey > > p.s. > > With > > "That used to be true, but the reason has nothing to do with the language. > The problem was that the libraries weren't there." > > What do you mean? Which packages should I be looking at? I am on iOS like > I said, its a stage 1 GHC compiler so I don't have access to GHCI or > template haskell. > > > >Casey Basichis <caseybasichis at gmail.com> wrote: > > > >> I'm not entirely sure what you mean. > >> > >> I'm intending on using Ogre for GUI - for which there is the Hogre > >> bindings, but after emailing the DEV about it, I didn't get the > >> impression from his advice that I should be using it for production > >> code. Here is what he suggested: > >> > >> "It depends, really. Hogre is good for running Ogre from within > >> Haskell, but it has its limitations. The number one thing people have > >> been struggling with is handling input with hogre - there's Hois > >> (Haskell wrapper for OIS) but it's not perfect (it misses input > >> events), and the other option is having to write some C++ glue. Hogre > >> is a solid proof of concept and you can do some demos with it, but if > >> you're e.g. writing a game it might be a bit of a struggle. In the end > >> it's about how much you value being able to write code in Haskell (or > >> how allergic to C++ you are)." > >> > >> I'm on iOS so I imagine those difficulties are compounded. > >> > >> I am using several other C++ libraries for which there are no existing > >> bindings and no Haskell alternative packages that are even remotely > >> close. > >> > >> Are you suggesting it would be better to write all my own FFI bindings > >> for all the needed libraries? > > > >That's not what I'm suggesting. It was just too little information to > >properly judge the difficulty of doing everything in Haskell. > > > >Binding to Ogre (or C++ in general) is indeed difficult. If Hogre > >doesn't work or is too limited, your best option might be to write a C > >wrapper around the Hogre functionality you need. Another option is to > >use SDL/OpenGL directly, which may be easier or harder depending on your > >application. > > > >However, if you can build the bridge between your rendering library and > >Haskell, then Haskell is certainly the better choice. > > > > > >> Everything I read suggests that Haskells strengths are in > >> transformation and that interaction is not its strong suit. > >> > >> I am interested in your thoughts and I am open to whatever, but you > >> are the first to suggest that the mix is a bad idea. > > > >That used to be true, but the reason has nothing to do with the > >language. The problem was that the libraries weren't there. Nowadays > >you can write all sorts of interactive applications in Haskell, > >including GUIs, TUIs, games, simulations and web applications. However, > >I've long been waiting for useful bindings to Ogre or Irrlicht, but I'm > >afraid that it's not going to happen any time soon. > > > >Ultimately it's your choice. Let me summarize the possiblities: > > > > * C wrapper around Ogre. Easy integration, but need to write the > > rendering code in C/C++. > > > > * Full FFI bindings to Ogre. Difficult integration, but you can write > > your rendering code in Haskell. > > > > * Partial FFI bindings to Ogre. Integration may be somewhat easy, if > > you do the initialization in Haskell and the actual rendering in > > C/C++. However, this again requires to write the rendering in > > C/C++. > > > > * Using SDL/OpenGL directly: Everything available for Haskell. May > > be difficult, because you need to write OpenGL code. > > > >I hope, this helps. > > > > > >Greets, > >Ertugrul > > > > -- > > Casey James Basichis > Composer - Cartoon Network > http://www.caseyjamesbasichis.com > caseybasic...@gmail.com > 310.387.7540 > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > >
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
