Rewrite the entire library in C

[Jeanne-Kamikaze]

Hi, can you rewrite the entire SFML library in C and then optionally make a C++ interface to it please ?

I've been trying to write Haskell bindings for SFML but there doesn't seem to be a way to do it without the resulting API sucking hard.

The problem is described here: http://hpaste.org/75677

Thanks.

[eXpl0it3r]

There's always a official CSFML binding...
A bit of research (mainly using the forum search function) would've brought this to light pretty quickly.

Wait you're already referring to CSFML...
So you don't want to rewrite the library in Haskel but you don't want to use any nasty ways either to connect SFML and Haskel and thus we should rewrite the whole library in (ugly) C, so you can use it better?
So basically you run into one problem and now 'the whole world' needs to change so you can fix your problem? Don't you think that's a bit too much asked?
Besides SFML is a C++ library and thus turning it into a C library with an 'optional' C++ interface will not happen. There's CSFML which should help other to create bindings but it's never said to be nice and it will never be nice.

[Jeanne-Kamikaze]

CSFML is SFML without classes or name mangling, i.e. it's still C++. When it comes to interfacing it from Haskell it's still a pain, for instance because CSFML structs like sfCircleShape contain C++ objects (with vtables) like CircleShape, making the interfacing in Haskell either horrible or simply non-portable (afaik at least).

Since building C bindings for C++ libraries is awkward, I was wondering if there was an ongoing effort to switch roles and make the library in C so that it could then be easily interfaced from other languages (such as C++), but from your reply I take it this is not the case.

And I don't think that's too much asked. After all, I'm trying to make your library available to more users.

Anyways, I'll see what I can do. I still think it's worth the effort to get some reasonable bindings.

[Laurent]

Types in CSFML are opaque types, no one is supposed to know what's behind those pointers, and no one should ever try to do something with that. I have no idea why you'd need to do that (all languages that I know are able to deal with a C API with opaque pointers, is Haskell that bad?), but forget about it. Even if it worked, it would be so ugly and a hell to maintain (because relying on internal structures that change often), that you would soon realize that it was a bad idea anyway.

So instead of asking for a complete rewrite of the library in order to allow your ugly implementation, you should find a clean way to interface CSFML and Haskell. I can't believe there's none.

[Jeanne-Kamikaze]

The problem is that the opaque types force me to write an impure API, which is not a problem with other languages because they are all impure. Stuff like Texture and Glyph aren't a problem, but stuff like CircleShape and ConvexShape should be able to be manipulated in a purely fashion. I suppose it's not impossible, but I nor the people who I have asked have found a nice way of doing it. Gonna have to give it some more thought.

[Laurent]

The problem is that the opaque types force me to write an impure API, which is not a problem with other languages because they are all impure.

Is this a joke, or does "impure" refer to something specific in the Haskell world?

[Jeanne-Kamikaze]

A pure function is one that is referentially transparent and has no side effects. The opaque types are forcing me to either write relatively innefficient code (mallocs behind the scenes) or write "impure" code (code that is trapped in the IO monad). Here I say "impure" because Haskell is technically pure.

[Jeanne-Kamikaze]

Like this:

[Laurent]

innefficient code (mallocs behind the scenes)

Is it really bad? There are mallocs in CSFML too.

Anyway, I won't rewrite SFML in C just because someone wants to write a "pure" Haskell binding, so you have to find another solution.

[MorleyDev]

You want a pure functional implementation...of a wrapper of a state-based graphical API?

......what?

[Jeanne-Kamikaze]

No, I want a pure implementation of the *Shape classes.

[Jeanne-Kamikaze]

It's not that big of a deal anyway as these are the only problematic classes and I've been told of a way to make the api more or less pure while minimising the number of background mallocs at the same time. Not perfect but quite passable.

[cekota]

(ugly) C

There are very often these kind of Trolls on this forum.

Please stop it.

C++ is also a horrible thing. No-one should use it to create a user app. C/C++ are fine to make low-level things. SFML does low-level things by interfacing with the windowing system. When you create a high level application you should use a high-level language. There are several high-level languages with very good performances. There are even some that provide the same performances than C/C++. Programming with a high level language makes you write things more easily, quickly, and with less bugs. The result will be easier to maintain, contributors will contribute more easily with a higher level language.

C is ugly, yes that's true, C++ is not better, it is a very complicated programming language. A lot of people around even say often that this is one of the most complecated programming language.

If you want to troll, I can troll with you too.

Please stop trolling.

[cekota]

If you use the shorthand terms "pure / impure" outside of a functional programming community some people won't understand you. Then you should use the complete expression, not a shorthand, like "purly functional", and for "impure", maybe "imperative" will be more easily understood by everyone.

Also in the Free/Libre software community things don't work as you think. You should not ask anyone to do something for you. Just take what's available, and do things yourself with it.

For your problem I'm not an expert, but if I remember correctly I think that I have read on this forum that in some situations, it could be better to reuse the same circle-shape, and just change the position (and maybe other params) for all the circles to be drawn.

So maybe you could use this same technic. Create a Circle structure on the Haskell side which will be purely functional.
Then the drawCircle will just check the fields of the Haskell structure (you could use Nothing/Just to limit things) and reuse all the time the same static (I mean not allocated but not with the static keyword) SFML CircleShape and call all the functions that are needed (like setFillColor() and co) and then the draw function.

What would you think of such a solution?

Also you say in one of your post that someone told you "of a way to make the api more or less pure while minimising the number of background mallocs at the same time". Please could you share it with us? I would be interested, maybe other people too.

[eXpl0it3r]

C++ is also a horrible thing. No-one should use it to create a user app. C/C++ are fine to make low-level things. SFML does low-level things by interfacing with the windowing system. When you create a high level application you should use a high-level language. There are several high-level languages with very good performances. There are even some that provide the same performances than C/C++. Programming with a high level language makes you write things more easily, quickly, and with less bugs. The result will be easier to maintain, contributors will contribute more easily with a higher level language.

C is ugly, yes that's true, C++ is not better, it is a very complicated programming language. A lot of people around even say often that this is one of the most complecated programming language.

Opinions, opinions there are many and everyone claims to have the truth.
If you can't accept that people which are into C++ don't like to see C code then you'll have a hard time, not only on this forum, but in mostly all C++ related forums/IRCs/etc.
Also degrading C++ to a low level language makes me think about what your definition of a high level language is or if you've ever looked at low level languages. C++ is a high level language and in my humble opinion there's no reason the switch to another language just because your opinion is that C++ isn't good to work with.
Additionally the language you choose does rarely have something to do with the possibility for maintenance nor contributions, this depends way more on the code design and the public interest.

And I can only mark this again in bold: this is my opinion.
Feel free to have your own, but getting newly on a forum and starting to call people trolls within the first few posts, just because he/she has a different opinion, doesn't really make a good look on yourself and it doesn't help to have a pleasant ambiance in here.
So please accept others opinion and if you want to discuss things do it without 'insulting' people you barely know.