Casey Basichis | 31 Jan 06:41 2013
Picon

FFI - Approaches to C/C++

Hi,

I'm working on a project in Haskell and C++ where the former is the brains and the latter is for UI, interaction etc.

I've read this http://www.altdevblogaday.com/2012/04/26/functional-programming-in-c/ and a number of other haskell posts suggesting the OOP is not the way to go.

Without trying to emulate functional programming through templates or boost::phoenix, what approaches do you all favor when designing parts of an application in C++?  Patterns to embrace or avoid?

Should I just use functions and handle things with name spaces?  I was thinking about handling the callbacks with boosts signals and slots 2

I know this is not entirely haskell centric, but it is a question for haskell users.

Thanks,
Casey

--
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
Ertugrul Söylemez | 31 Jan 07:32 2013
Picon

Re: FFI - Approaches to C/C++

Casey Basichis <caseybasichis <at> gmail.com> wrote:

> I'm working on a project in Haskell and C++ where the former is the
> brains and the latter is for UI, interaction etc.

That's a rather odd choice.  Not exactly answering your question, but
questioning your project decisions, why would you do UI and interaction
in C++?  You have the necessary Haskell bindings and libraries to write
everything cleanly in Haskell.

Greets,
Ertugrul

--

-- 
Not to be or to be and (not to be or to be and (not to be or to be and
(not to be or to be and ... that is the list monad.
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Casey Basichis | 31 Jan 08:08 2013
Picon

Re: FFI - Approaches to C/C++

Hi Ertugrul,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? 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. Thanks,Casey
>> I'm working on a project in Haskell and C++ where the former is the >> brains and the latter is for UI, interaction etc. >That's a rather odd choice. Not exactly answering your question, but >questioning your project decisions, why would you do UI and interaction >in C++? You have the necessary Haskell bindings and libraries to write >everything cleanly in Haskell. > > >Greets, >Ertugrul
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Ertugrul Söylemez | 31 Jan 09:23 2013
Picon

Re: FFI - Approaches to C/C++

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

--

-- 
Key-ID: E5DD8D11 "Ertugrul Soeylemez <es <at> ertes.de>"
FPrint: BD28 3E3F BE63 BADD 4157  9134 D56A 37FA E5DD 8D11
Keysrv: hkp://subkeys.pgp.net/
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
kudah | 5 Feb 04:56 2013
Picon

Re: FFI - Approaches to C/C++

I'd object to your implication that Haskell is completely ready for
use in general soft real-time systems. I was unable to implement a
multi-threaded application which does a some IO-work in background
threads in a way so that its GUI won't die. Worker threads simply
starve the GUI, because Haskell doesn't have thread priorities. And
even if it had, it would still lag on Windows, due to lack of IO
manager. Ezyang had, in fact, made a new scheduler, which seems to
address the problem; and joeyadams tries to make IO-manager for
windows, but all this isn't going to see the light of day for a while,
at least until 7.8.1.

2013/1/31 Ertugrul Söylemez <es <at> ertes.de>:
> 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.

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Carlo Hamalainen | 5 Feb 05:55 2013
Picon

Re: FFI - Approaches to C/C++

On Tue, Feb 5, 2013 at 1:56 PM, kudah <kudahkukarek <at> gmail.com> wrote:

I'd object to your implication that Haskell is completely ready for
use in general soft real-time systems. I was unable to implement a
multi-threaded application which does a some IO-work in background
threads in a way so that its GUI won't die. Worker threads simply
starve the GUI, because Haskell doesn't have thread priorities. And
even if it had, it would still lag on Windows, due to lack of IO
manager. Ezyang had, in fact, made a new scheduler, which seems to
address the problem; and joeyadams tries to make IO-manager for
windows, but all this isn't going to see the light of day for a while,
at least until 7.8.1.

What did you use for the GUI? WxWidgets?

I'm interested in this case because I develop a cross-platform Python GUI application and would like to see how a Haskell implementation would behave.

--
Carlo Hamalainen
http://carlo-hamalainen.net
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
kudah | 5 Feb 07:35 2013
Picon

Re: FFI - Approaches to C/C++

I used gtk2hs, because I couldn't find a free software design tool that was
at least as good as glade3. Last time I tried to compile wxHaskell, wxc
produced an enormous dynamic library which also linked to every
wxWidgets library out there(e.g. wxwebkit), so that the resulting mess
couldn't be reasonably distributed in binaries.

2013/2/5 Carlo Hamalainen <carlo.hamalainen <at> gmail.com>:
> On Tue, Feb 5, 2013 at 1:56 PM, kudah <kudahkukarek <at> gmail.com> wrote:
>>
>> I'd object to your implication that Haskell is completely ready for
>> use in general soft real-time systems. I was unable to implement a
>> multi-threaded application which does a some IO-work in background
>> threads in a way so that its GUI won't die. Worker threads simply
>> starve the GUI, because Haskell doesn't have thread priorities. And
>> even if it had, it would still lag on Windows, due to lack of IO
>> manager. Ezyang had, in fact, made a new scheduler, which seems to
>> address the problem; and joeyadams tries to make IO-manager for
>> windows, but all this isn't going to see the light of day for a while,
>> at least until 7.8.1.
>
>
> What did you use for the GUI? WxWidgets?
>
> I'm interested in this case because I develop a cross-platform Python GUI
> application and would like to see how a Haskell implementation would behave.
>
> --
> Carlo Hamalainen
> http://carlo-hamalainen.net
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe <at> haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
Ertugrul Söylemez | 5 Feb 06:23 2013
Picon

Re: FFI - Approaches to C/C++

kudah <kudahkukarek <at> gmail.com> wrote:

> I'd object to your implication that Haskell is completely ready for
> use in general soft real-time systems. I was unable to implement a
> multi-threaded application which does a some IO-work in background
> threads in a way so that its GUI won't die. Worker threads simply
> starve the GUI, because Haskell doesn't have thread priorities. And
> even if it had, it would still lag on Windows, due to lack of IO
> manager. Ezyang had, in fact, made a new scheduler, which seems to
> address the problem; and joeyadams tries to make IO-manager for
> windows, but all this isn't going to see the light of day for a while,
> at least until 7.8.1.

Be sure to compile with -threaded.  Also note that GUI libraries often
want to run in a bound thread.

Greets,
Ertugrul

--

-- 
Key-ID: E5DD8D11 "Ertugrul Soeylemez <es <at> ertes.de>"
FPrint: BD28 3E3F BE63 BADD 4157  9134 D56A 37FA E5DD 8D11
Keysrv: hkp://subkeys.pgp.net/
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
kudah | 5 Feb 07:41 2013
Picon

Re: FFI - Approaches to C/C++

I followed dmwit's guide on threaded gtk2hs, all GUI interaction is in the
main thread, which is always bounded. This shouldn't really impact the
lag, as soon as gtk2hs calls back to haskell, nothing stops the RTS
from delaying main thread's peaceful return to C-land for arbitrary amount
of time.

2013/2/5 Ertugrul Söylemez <es <at> ertes.de>:
> Be sure to compile with -threaded.  Also note that GUI libraries often
> want to run in a bound thread.

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Donn Cave | 31 Jan 09:36 2013

Re: FFI - Approaches to C/C++

Quoth Casey Basichis <caseybasichis <at> gmail.com>,
...
> 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?
> 
> Everything I read suggests that Haskells strengths are in
> transformation and that interaction is not its strong suit.

I've done it, for my own amusement - wrapped a C++ graphics toolkit
and used it to write a couple small applications.

Most of us would probably object to your transformation/interaction
evaluation as presented above ... but it depends on your motivations.

In my case, I simply wanted to use Haskell, and in fact I started
with a model like yours where the UI was simply written in C++.
There were some very cumbersome things about that arrangement though,
so I was happy to integrate Haskell into the UI as soon as it became
possible.  On the other hand ... I'd be lying if I said the Haskell
code is "cleaner", or really advantageous in any compelling way if
we're just talking about the UI.  It has its moments - Haskell is
always going to pull a few things off pretty well, in a UI or whatever -
but of course, this particular UI API is specifically more suited
to C++, than Haskell.  So given that one can write good, clean code
in C++, too, the question is whether Haskell is so vastly advantageous
for such applications that it compensates for the sketchy binding.
It isn't, I think.

Whereupon we come to your original question.  Personally, I would
just work with the model that's natural to your API.  If it's a
C++ OO 3D graphics library, then go OO, for the very same reasons
discussed above.  FP may in principle have all the virtues mentioned
in that article, and it's good to be on the lookout for ways you can
deploy some of that in a C++ program, but when it comes time to use
that OO API, it's what you've got.

	Donn
Casey Basichis | 31 Jan 09:53 2013
Picon

Re: FFI - Approaches to C/C++

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
Alexander Kjeldaas | 31 Jan 11:41 2013
Picon

Re: FFI - Approaches to C/C++


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 <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


_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Rustom Mody | 31 Jan 13:32 2013
Picon

Re: FFI - Approaches to C/C++



On Thu, Jan 31, 2013 at 11:11 AM, Casey Basichis <caseybasichis <at> gmail.com> wrote:
Hi,

I'm working on a project in Haskell and C++ where the former is the brains and the latter is for UI, interaction etc.

I've read this http://www.altdevblogaday.com/2012/04/26/functional-programming-in-c/ and a number of other haskell posts suggesting the OOP is not the way to go.

Without trying to emulate functional programming through templates or boost::phoenix, what approaches do you all favor when designing parts of an application in C++?  Patterns to embrace or avoid?

Should I just use functions and handle things with name spaces?  I was thinking about handling the callbacks with boosts signals and slots 2

I know this is not entirely haskell centric, but it is a question for haskell users.

Thanks,
Casey

And then

I'm on iOS so I imagine those difficulties are compounded.
 
If you can tolerate the view that Haskell is more of an ideology than a technology, and are willing to explore areas that are technologically disparate but conceptually similar to Haskell maybe you should look at ocaml:
http://web.yl.is.s.u-tokyo.ac.jp/~tosh/ocaml-on-iphone/index.html
http://psellos.com/ocaml/compile-to-iphone.html


Rusi
--
http://www.the-magus.in
http://blog.languager.org

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Gmane