No subject
Thu Jan 10 18:17:16 CET 2013
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 <caseybasichis at 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
> caseybasichis at gmail.com
> 310.387.7540
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>
--14dae93403ebb434de04d49347cd
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div style>From my experience, these things are needed=
to get solid (i.e. not flaky software) results.</div><div style>This is no=
t what normal Haskell bindings look like though:</div><div style><br></div>
<div style>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.</div><div style>2. Create a mock implementation =
of the Haskell side if it is accessed from C++.<br>
</div><div style>3. Create comprehensive C++ only tests (using mock Haskell=
) that runs cleanly through valgrind.</div><div style>4. Create as small an=
interface between C++ and Haskell as possible.</div><div style>5. If you h=
ave a wide API that has little performance implications between Haskell and=
C++, consider not using the FFI directly, but a higher-level abstraction s=
uch as protocol buffers for this part of your API.</div>
<div style><br></div><div style>Alexander</div><div style><br></div></div><=
div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Thu, Jan 31=
, 2013 at 9:53 AM, Casey Basichis <span dir=3D"ltr"><<a href=3D"mailto:c=
aseybasichis at gmail.com" target=3D"_blank">caseybasichis at gmail.com</a>></=
span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">Hi Ertugrul,<br><div class=
=3D"gmail_quote"><div dir=3D"ltr"><div><br></div><div>Thank you for the det=
ailed reply. =C2=A0From what you wrote, partial FFI still seems like the wa=
y to go.</div>
<div><br></div><div>Unfortunately Ogre isn't the only large library I&#=
39;m using, so "difficult" several times over sounds like a good =
way to handicap the project early on.</div>
<div><br></div><div>I'm perfectly happy to use Haskell for the strength=
s that will most benefit my project. =C2=A0I can always go back and try to =
bring the C++ specific parts into the fold once a prototype is up and runni=
ng.</div>
<div><br></div><div>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.</=
div><div><br></div><div>What practices in C++ are preferred by Haskell user=
s, in the know, for the parts of the app that will not be pure Haskell?</di=
v>
<div><br></div><div>Should I be looking to avoid OOP? =C2=A0Dependency Inje=
ction? 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 minimize=
d the damage I inflict in c++ land.</div>
<div><br></div><div>Thanks,</div><div>Casey</div><div><br></div><div>p.s.</=
div><div><br></div><div>With</div><div class=3D"im"><div><br></div><div>&qu=
ot;That used to be true, but the reason has nothing to do with the language=
. =C2=A0The problem was that the libraries weren't there."</div>
<div><br></div></div><div>What do you mean? Which packages should I be look=
ing at? =C2=A0I am on iOS like I said, its a stage 1 GHC compiler so I don&=
#39;t have access to GHCI or template haskell.</div><div class=3D"im"><div>=
<br>
</div><div><br></div>
<div>>Casey Basichis <caseybasichis at=C2=A0<a href=3D"http://gmail.c=
om/" target=3D"_blank">gmail.com</a>> wrote:</div><div>></div><div>&g=
t;> I'm not entirely sure what you mean.</div><div>>></div><di=
v>>> I'm intending on using Ogre for GUI - for which there is the=
Hogre</div>
<div>>> bindings, but after emailing the DEV about it, I didn't g=
et the</div><div>>> impression from his advice that I should be using=
it for production</div><div>>> code. =C2=A0Here is what he suggested=
:</div>
<div>>></div><div>>> "It depends, really. Hogre is good fo=
r running Ogre from within</div><div>>> Haskell, but it has its limit=
ations. The number one thing people have</div><div>>> been struggling=
with is handling input with hogre - there's Hois</div>
<div>>> (Haskell wrapper for OIS) but it's not perfect (it misses=
input</div><div>>> events), and the other option is having to write =
some C++ glue. Hogre</div><div>>> is a solid proof of concept and you=
can do some demos with it, but if</div>
<div>>> you're e.g. writing a game it might be a bit of a struggl=
e. In the end</div><div>>> it's about how much you value being ab=
le to write code in Haskell (or</div><div>>> how allergic to C++ you =
are)."</div>
<div>>></div><div>>> I'm on iOS so I imagine those difficul=
ties are compounded.</div><div>>></div></div><div class=3D"im"><div>&=
gt;> I am using several other C++ libraries for which there are no exist=
ing</div>
<div>>> bindings and no Haskell alternative packages that are even re=
motely</div>
<div>>> close.</div><div>>></div><div>>> Are you suggesti=
ng it would be better to write all my own FFI bindings</div><div>>> f=
or all the needed libraries?</div><div>></div></div><div class=3D"im">
<div>>That's not what I'm suggesting. =C2=A0It was just too litt=
le information to</div>
<div>>properly judge the difficulty of doing everything in Haskell.</div=
><div>></div><div>>Binding to Ogre (or C++ in general) is indeed diff=
icult. =C2=A0If Hogre</div><div>>doesn't work or is too limited, you=
r best option might be to write a C</div>
<div>>wrapper around the Hogre functionality you need. =C2=A0Another opt=
ion is to</div><div>>use SDL/OpenGL directly, which may be easier or har=
der depending on your</div><div>>application.</div><div>></div><div>&=
gt;However, if you can build the bridge between your rendering library and<=
/div>
<div>>Haskell, then Haskell is certainly the better choice.</div><div>&g=
t;</div><div>></div></div><div class=3D"im"><div>>> Everything I r=
ead suggests that Haskells strengths are in</div><div>>> transformati=
on and that interaction is not its strong suit.</div>
<div>>></div></div><div class=3D"im"><div>>> I am interested in=
your thoughts and I am open to whatever, but you</div><div>>> are th=
e first to suggest that the mix is a bad idea.</div><div>></div><div>
>That used to be true, but the reason has nothing to do with the</div>
<div>>language. =C2=A0The problem was that the libraries weren't the=
re. =C2=A0Nowadays</div><div>>you can write all sorts of interactive app=
lications in Haskell,</div><div>>including GUIs, TUIs, games, simulation=
s and web applications. =C2=A0However,</div>
<div>>I've long been waiting for useful bindings to Ogre or Irrlicht=
, but I'm</div><div>>afraid that it's not going to happen any ti=
me soon.</div><div>></div><div>>Ultimately it's your choice. =C2=
=A0Let me summarize the possiblities:</div>
<div>></div><div>> =C2=A0* C wrapper around Ogre. =C2=A0Easy integrat=
ion, but need to write the</div><div>> =C2=A0 =C2=A0rendering code in C/=
C++.</div><div>></div><div>> =C2=A0* Full FFI bindings to Ogre. =C2=
=A0Difficult integration, but you can write</div>
<div>> =C2=A0 =C2=A0your rendering code in Haskell.</div><div>></div>=
<div>> =C2=A0* Partial FFI bindings to Ogre. =C2=A0Integration may be so=
mewhat easy, if</div><div>> =C2=A0 =C2=A0you do the initialization in Ha=
skell and the actual rendering in</div>
<div>> =C2=A0 =C2=A0C/C++. =C2=A0However, this again requires to write t=
he rendering in</div><div>> =C2=A0 =C2=A0C/C++.</div><div>></div><div=
>> =C2=A0* Using SDL/OpenGL directly: =C2=A0Everything available for Has=
kell. =C2=A0May</div><div>> =C2=A0 =C2=A0be difficult, because you need =
to write OpenGL code.</div>
<div>></div><div>>I hope, this helps.</div><div>></div><div>></=
div><div>>Greets,</div><div>>Ertugrul</div></div></div></div><br><br =
clear=3D"all"><div><br></div>--=C2=A0<div class=3D"im"><br>Casey James Basi=
chis<br>
Composer - Cartoon Network<br>
<a href=3D"http://www.caseyjamesbasichis.com/" target=3D"_blank">http://www=
.caseyjamesbasichis.com</a><br><a href=3D"mailto:caseybasichis at gmail.com" t=
arget=3D"_blank">caseybasichis at gmail.com</a><br>310.387.7540<br></div></div=
>
<br>_______________________________________________<br>
Haskell-Cafe mailing list<br>
<a href=3D"mailto:Haskell-Cafe at haskell.org">Haskell-Cafe at haskell.org</a><br=
>
<a href=3D"http://www.haskell.org/mailman/listinfo/haskell-cafe" target=3D"=
_blank">http://www.haskell.org/mailman/listinfo/haskell-cafe</a><br>
<br></blockquote></div><br></div>
--14dae93403ebb434de04d49347cd--
More information about the Haskell-Cafe
mailing list