Re: BAL paper available >> graphic libraries

[[Perhaps, if this thread continues, it is time to move to a nice -café at the corner.]] Timothy Docker:
Has anyone considered writing a haskell wrapper for SDL - Simple Directmedia Layer at http://www.libsdl.org ?
This is a cross platform library intended for writing games, and aims for a high performance, low level API. It would be interesting to see how clean a functional API could be built around such an imperative framework.
Ammmmm...... I didn't want to touch this issue, but, well, indeed, I had a look on Sam Lantinga's SDL package some time ago (I believe, a new version exists now). I know that Johnny Andersen (somewhere near DIKU, plenty of craziness on his ÁNOQ pages...) produced a Standard ML bindings for that. But reading this stuff I was simply scared to death! Using simultaneously 6 compilers, passing through "C" code, etc. - my impression was: OK, it should work. If somebody wants to write a game, a concrete simulation in ML, it might help him. But, on the other hand if you want to have a decent programming platform, enabling you to write - even (or: especially) for pedagogical purposes some graphic tools of universal character, say, * a model ray tracer with the "native" scene description language (i.e. the same language for the core implementation, and for the scene/object description, and for its scripting (animation)), * a generic texture generator and image processing toolbox with all such stuff as relational algebra of images, math. morphology, etc., * a radiosity machine * ... dozen of other projects ... then without a common memory management, without rebuilding the - say - Haskell runtime *with* SDL or other low-level graphics utilities, it might be difficult to use. The approach taken by Clean'ers, to have an "almost intrinsic" graphic object-oriented IO layer, and building their Game Library upon it, seems more reasonable, and at any rate it has more sex-appeal for those who are truly interested in practical functional programming as such, and not just in stacking some external goodies which integrate badly with the language. Bother, I realized that my main contributions to this list are just complaining. Somebody could teleport me to a desert island, with some computers, but without hoards of students just for 6 months? Jerzy Karczmarczuk Caen, France

Jerzy Karczmarczuk wrote:
[[Perhaps, if this thread continues, it is time to move to a nice -café at the corner.]]
Timothy Docker:
Has anyone considered writing a haskell wrapper for SDL - Simple Directmedia Layer at http://www.libsdl.org ?
This is a cross platform library intended for writing games, and aims for a high performance, low level API. It would be interesting to see how clean a functional API could be built around such an imperative framework.
Yes, SDL is a very interesting library, I wrote a wrapper for part of it a while ago: http://www.science.uva.nl/~kort/sdlhs/ It's far from complete and I have no plans to work on it. But for trying out graphics stuff it's very useful, mainly because you can understand the whole thing, fix it if it breaks down: make some change and recompile the whole wrapper in a minute or so.
Ammmmm...... I didn't want to touch this issue, but, well, indeed, I had a look on Sam Lantinga's SDL package some time ago (I believe, a new version exists now). I know that Johnny Andersen (somewhere near DIKU, plenty of craziness on his ÁNOQ pages...) produced a Standard ML bindings for that. But reading this stuff I was simply scared to death! Using simultaneously 6 compilers, passing through "C" code, etc. - my impression was: OK, it should work. If somebody wants to write a game, a concrete simulation in ML, it might help him.
I tried to install tbat stuff a while ago, I spend 2 days cursing and after a friendly but unhelpful email exchange I gave up.. I have no clue how to get that stuff working. Sounded really cool though: an ML implementation that is on average 3 times as fast as SML/NJ, a lightweight C interface, support for crosscompiling ML+SDL applications from Linux to Windows. Maybe I should try one more time.. Jan
participants (2)
-
Jan Kort
-
Jerzy Karczmarczuk