<div dir="ltr"><div>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.<br></div><div>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.</div><div><br></div><div>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:</div><div><br></div><div>* SDL needs to explicitly use get/set everywhere</div><div>* SDL copies Data.StateVar and uses it locally. Now all the names have to be imported qualified, and things got a ton harder</div><div>* 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*!)</div><div><br></div><div>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.</div><div><br></div><div>+1, if that's wasn't obvious ;)</div><div><br></div><div>- ocharles</div></div>