[Haskell] ANNOUNCE: OpenGLRaw 18.104.22.168
Sven.Panne at aedion.de
Fri Jun 12 05:24:19 EDT 2009
Am Donnerstag, 11. Juni 2009 19:23:17 schrieb Bryan O'Sullivan:
> Since this is a new package, is there any possibility that the naming could
> be more economical?
> Graphics.Rendering.OpenGL.GL.CoordTrans is awfully long.
> I think that "Graphics.Rendering." is clutter, and "OpenGL.GL." seems
> redundant to me. I'd very much like to encourage the idea that tremendously
> long package names ought to be considered poor form.
While I consider this a bit long, too, there are a few reasons why it was done
this way. The OpenGLRaw package exports 1025 functions, 1673 tokens and 20
types, so one clearly needs some way of structuring this, the only question is
You rarely import on such a fine-grained level, most of the time you simply
use the rather short
import, where you can even add "as GL" if you like for short explicit
qualification later. Another example: If you explicitly only want to use pure,
modern OpenGL 3.1 "the raw way", use:
If you additionally want to use the ARB_compatibility extension, use:
If you want the OpenGL 3.1 core plus all ARB extensions, use
And if you are very lazy, you can simply pull in the whole raw binding with
This leaves the decision about the granularity of the import to the user of
the package, which is a good thing IMHO. The ".Raw" part is necessary to
distinguish between the raw and the nice interface, leaving the dot out or
replacing it with "_" wouldn't really buy us much.
One point here is debatable: Do we really need the ".Rendering" part in the
package name or would simply "Graphics.OpenGL.Raw" be enough? We discussed the
structure of the hierarchy when hierarchical packages were in their infancy,
many years ago, and it was consensus then to distinguish between
"Graphics.Rendering" and "Graphics.UI". I don't have very strong feelings
about ".Rendering" and ".UI", and if the consensus nowadays is to remove it,
I'll be happy to change this. But let's move the discussion about this to the
libraries mailing list.
A few final remarks: Leaving out "Graphics." completely would be a very bad
idea, the naming hierarchy should reflect the underlying conceptual hierarchy.
The only problem with hierarchies in general is that sometimes the position in
it is not very clear. I have e.g. never fully understood why "Monad" and
"Applicative" are below "Control", but "Foldable" is below "Data"...
More information about the Haskell