Adding infix declaration to StateVar operators - HOpenGL - Haskell.org

newer
Important changes to OpenGLRaw

Adding infix declaration to StateVar operators

older
How to send matrices to GLSL...

Paul Visschers

22 Jul 2012 22 Jul '12

9:38 a.m.

Hey, I would like to suggest adding an infixr 2 for the ($~), ($=!) and ($~!) operators in the StateVar package. Paul

Attachments:

attachment.html (text/html — 168 bytes)

Reply

Sign in to reply online Use email software

Show replies by date

L Corbijn

27 Aug 27 Aug

1:46 p.m.

Ok, I've done this and added the package to github [1]. There are still some things to do before a release: - Move the repository to the HOpenGL organisation. - Update several fields in cabal file (bug tracker, owner, etc.) - Bump the version number. The new version number should probably be 1.0.1.0, but 1.1.0.0 could also be correct. The latter would break several packages [2]. Greetings, Lars [1] https://github.com/Laar/StateVar [2] http://packdeps.haskellers.com/reverse/StateVar On Sun, Jul 22, 2012 at 11:38 AM, Paul Visschers wrote:

Hey,

I would like to suggest adding an infixr 2 for the ($~), ($=!) and ($~!) operators in the StateVar package.

Paul

_______________________________________________ HOpenGL mailing list HOpenGL@haskell.org http://www.haskell.org/mailman/listinfo/hopengl

Reply

Sign in to reply online Use email software

Jason Dagit

23 Sep 23 Sep

10:35 p.m.

On Mon, Aug 27, 2012 at 6:46 AM, L Corbijn wrote:

Ok, I've done this and added the package to github [1]. There are still some things to do before a release: - Move the repository to the HOpenGL organisation.

Done.

- Update several fields in cabal file (bug tracker, owner, etc.)

I have those changes locally, but they are mixed in with a namespace change.

- Bump the version number.

I have it locally, going with 1.1.0.0.

The new version number should probably be 1.0.1.0, but 1.1.0.0 could also be correct. The latter would break several packages [2].

I think the right thing is to let the maintainers reupload them. The ones that will break have not been following the PVP. Breaking other people's code is not good, but I think this is pretty minor. I was going to bring up the namespace change, but the more I think about it the more it seems wrong to me. The current name makes this package controversial for the Haskell Platform. The reason for having such a general name is OpenAL and ALUT use the same abstraction. My initial thought was to move it to Graphics.Rendering.OpenGL.StateVar. Then it's obviously an OpenGL state variable abstraction. Unfortunately, that doesn't work will with OpenAL and ALUT using it too. It also seems bad to have two different copies of the abstraction in play for people that want to combine OpenAL and OpenGL. So I think Sven made the right decision when he separated out the package and abstracted the namespace. Could we pick a less controversial place in the namespace? Reviewing this: http://www.haskell.org/haskellwiki/Hierarchical_module_names The closest I can come to better namespaces are these (but, I don't like them, read on): System.IO.StateVar Data.IO.StateVar Data.IO does not exist yet and System.IO is actually for interacting with the operating environment (like file manipulation). I feel like procrastinating more on this namespace change. It just doesn't feel right and I have no evidence that the HP will take it if I rename it. I'll finish the other changes and push to the develop branch on haskell-opengl. I could release it too if others agree it's ready. Jason

Reply

Sign in to reply online Use email software

L Corbijn

26 Sep 26 Sep

3:14 p.m.

On Mon, Sep 24, 2012 at 12:35 AM, Jason Dagit wrote:

On Mon, Aug 27, 2012 at 6:46 AM, L Corbijn wrote:

...
Ok, I've done this and added the package to github [1]. There are still some things to do before a release: - Move the repository to the HOpenGL organisation.

Done.

...
- Update several fields in cabal file (bug tracker, owner, etc.)

I have those changes locally, but they are mixed in with a namespace change.

...
- Bump the version number.

I have it locally, going with 1.1.0.0.

...
The new version number should probably be 1.0.1.0, but 1.1.0.0 could also be correct. The latter would break several packages [2].

I think the right thing is to let the maintainers reupload them. The ones that will break have not been following the PVP. Breaking other people's code is not good, but I think this is pretty minor.

I was going to bring up the namespace change, but the more I think about it the more it seems wrong to me. The current name makes this package controversial for the Haskell Platform. The reason for having such a general name is OpenAL and ALUT use the same abstraction. My initial thought was to move it to Graphics.Rendering.OpenGL.StateVar. Then it's obviously an OpenGL state variable abstraction. Unfortunately, that doesn't work will with OpenAL and ALUT using it too. It also seems bad to have two different copies of the abstraction in play for people that want to combine OpenAL and OpenGL.

So I think Sven made the right decision when he separated out the package and abstracted the namespace. Could we pick a less controversial place in the namespace?

Reviewing this: http://www.haskell.org/haskellwiki/Hierarchical_module_names

The closest I can come to better namespaces are these (but, I don't like them, read on): System.IO.StateVar Data.IO.StateVar

Data.IO does not exist yet and System.IO is actually for interacting with the operating environment (like file manipulation).

I feel like procrastinating more on this namespace change. It just doesn't feel right and I have no evidence that the HP will take it if I rename it.

I'll finish the other changes and push to the develop branch on haskell-opengl. I could release it too if others agree it's ready.

Jason

I don't see why it shouldn't be ready to release after updating the cabal file. StateVar is almost as small and simple abstraction as is possible (and should be) that it can't be not ready. About the namsepaces, I think the current place is the most sensible option for the moment. Data.IO.StateVar would be nice, but creating Data.IO just for StateVar is not to my liking. Lars

Reply

Sign in to reply online Use email software

4666

Age (days ago)

4732

Last active (days ago)

Download

3 comments

3 participants

tags

participants (3)

Jason Dagit
L Corbijn
Paul Visschers