Proposal: Let OpenGL depend on the StateVar package

Oliver Charles ollie at ocharles.org.uk
Wed Oct 22 22:01:32 UTC 2014


I'm not up to date on why this didn't happen last time, but I can
appreciate it being an unnecessary change. However, now the change seems to
be more substantiated.
Firstly, as others have expressed - this is a common pattern in C libraries
where mutation through IO is really the only way to go. A single name to
encapsulate both sides of the equation is pretty nice here - it drastically
reduces the API size which leads to libraries that (I believe) are easier
to learn.

This usage is particularly telling though, because this an abstraction
that's likely to be used by both of these libraries in the majority of
projects. While it's true you don't have to use SDL with OpenGL, my hunch
is that the majority will. If we can't get this stuff factored out to a
common library then:

* SDL needs to explicitly use get/set everywhere
* SDL copies Data.StateVar and uses it locally. Now all the names have to
be imported qualified, and things got a ton harder
* SDL has its own Data.StateVar with different names. Now we've put burden
on the user to juggle between various names, and introduced even more
operators (many already believe Haskell has too many - I'd rather not add
*more*!)

None of these are compelling options, and it'll be a real shame if OpenGL
dominates this design pattern - essentially ruling out its usage in the
game development/graphics programming community.

+1, if that's wasn't obvious ;)

- ocharles
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20141022/574074a9/attachment-0001.html>


More information about the Libraries mailing list