ANNOUNCE: OpenGLRaw 1.0.0.0
As a first step to make the OpenGL package easier to install, more modular and a bit more flexible, a low-level binding for OpenGL has been uploaded to Hackage. From OpenGLRaw's package description: ------------------------------------------------------------ OpenGLRaw is a raw Haskell binding for the OpenGL 3.1 graphics system and lots of OpenGL extensions. It is basically a 1:1 mapping of OpenGL's C API, intended as a basis for a nicer interface. OpenGLRaw offers access to all necessary functions, tokens and types plus a general facility for loading extension entries. The module hierarchy closely mirrors the naming structure of the OpenGL extensions, making it easy to find the right module to import. All API entries are loaded dynamically, so no special C header files are needed for building this package. If an API entry is not found at runtime, a userError is thrown. OpenGL is the industry's most widely used and supported 2D and 3D graphics application programming interface (API), incorporating a broad set of rendering, texture mapping, special effects, and other powerful visualization functions. For more information about OpenGL and its various extensions, please see http://www.opengl.org/ and http://www.opengl.org/registry/. ------------------------------------------------------------ Version 1.0.0.0 covers the OpenGL 3.1 core, all ARB extensions and all EXT extensions. Great care has been taken to introduce as few build dependencies as possible, so neither autoconf is required, nor any OpenGL headers. Future versions of the OpenGL package will basically be a convenience layer above this package, but you can always fall back to the raw binding if required. To get a taste for it, have a look at http://aedion.de/haskell/SmoothRaw.hs, which should look extremely familiar to anyone who has used OpenGL's C API. Any feedback is highly appreciated. Cheers, S.
On Thu, Jun 11, 2009 at 9:56 AM, Sven Panne <Sven.Panne@aedion.de> wrote:
Any feedback is highly appreciated.
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.
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.
... or be made abstractable, e.g.: import prefix Graphics.Rendering.OpenGL.GL as OpenGL import OpenGL.CoordTrans Wolfram
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 how. You rarely import on such a fine-grained level, most of the time you simply use the rather short import Graphics.Rendering.OpenGL 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: import Graphics.Rendering.OpenGL.Raw.Core31 If you additionally want to use the ARB_compatibility extension, use: import Graphics.Rendering.OpenGL.Raw.Core31 import Graphics.Rendering.OpenGL.Raw.ARB.Compatibility If you want the OpenGL 3.1 core plus all ARB extensions, use import Graphics.Rendering.OpenGL.Raw.Core31 import Graphics.Rendering.OpenGL.Raw.ARB And if you are very lazy, you can simply pull in the whole raw binding with import Graphics.Rendering.OpenGL.Raw 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"... Cheers, S.
Am Freitag, 12. Juni 2009 11:24 schrieb Sven Panne:
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"...
This is a reason for me thinking that the naming hierarchy should not reflect the underlying conceptual hierarchy (completely). I’d like to propose a more flat structure. The Yampa people and I (the Grapefruit maintainer) already agreed to introduce a top-level FRP namespace instead of putting FRP under Control or whatever. Graphics.UI is a bad choice in my opinion, since not all user interfaces are graphical (ncurses) and for those who are, it’s not so important anymore that they are (it was important in the 1980ies). So it might be good to change Graphics.UI to just UI. Then we might want to change Graphics.Rendering to just Graphics. What do others think? Best wishes, Wolfgang
I completely agree with Wolfgang, but still, defining a hierarchy, even if it is almost flat, is always difficult. I remember when I made videogames in a big team that we had endless discussions of how to arrange the directory structures, only to find out that hierarchies are not ideal, they are a compromise (IMHO for many tasks simple tagging or relation database approaches often work much better to organize data) Cheers, Peter Verswyvelen Software Architect www.anygma.com -----Original Message----- From: haskell-bounces@haskell.org [mailto:haskell-bounces@haskell.org] On Behalf Of Wolfgang Jeltsch Sent: Tuesday, June 16, 2009 2:37 PM To: haskell@haskell.org Subject: Re: [Haskell] ANNOUNCE: OpenGLRaw 1.0.0.0 Am Freitag, 12. Juni 2009 11:24 schrieb Sven Panne:
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"...
This is a reason for me thinking that the naming hierarchy should not reflect the underlying conceptual hierarchy (completely). I’d like to propose a more flat structure. The Yampa people and I (the Grapefruit maintainer) already agreed to introduce a top-level FRP namespace instead of putting FRP under Control or whatever. Graphics.UI is a bad choice in my opinion, since not all user interfaces are graphical (ncurses) and for those who are, it’s not so important anymore that they are (it was important in the 1980ies). So it might be good to change Graphics.UI to just UI. Then we might want to change Graphics.Rendering to just Graphics. What do others think? Best wishes, Wolfgang _______________________________________________ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell __________ Information from ESET Smart Security, version of virus signature database 4159 (20090616) __________ The message was checked by ESET Smart Security. http://www.eset.com __________ Information from ESET Smart Security, version of virus signature database 4159 (20090616) __________ The message was checked by ESET Smart Security. http://www.eset.com
(moving to Libraries list) Wolfgang Jeltsch wrote:
The Yampa people and I (the Grapefruit maintainer) already agreed to introduce a top-level FRP namespace instead of putting FRP under Control or whatever. Graphics.UI is a bad choice in my opinion, since not all user interfaces are graphical (ncurses) and for those who are, it’s not so important anymore that they are (it was important in the 1980ies). So it might be good to change Graphics.UI to just UI. Then we might want to change Graphics.Rendering to just Graphics.
What do others think?
I prefer this too. UI and Graphics are different things: doing stuff with images is graphics but not UI, while ncurses or even a command-line is UI but not graphics. -- Ashley Yakeley
Wolfgang Jeltsch <g9ks157k@acme.softbase.org> wrote:
The Yampa people and I (the Grapefruit maintainer) already agreed to introduce a top-level FRP namespace instead of putting FRP under Control or whatever.
The problem with a top-level namespace like FRP is that it is a cryptic acronym: it means nothing to a novice, and may be easily confused with other acronyms by an expert. I believe top-level names should _at_the_ _very_least_ be minimally descriptive of the category of things that live in it. So, I'd be fine with Control.Reactive.FRP, Control.Reactive.Yampa, etc, or even just Reactive.Yampa etc. I do understand that hierarchical classification is inherently problematic, and will never quite fit the ways we think of our modules. But the alternative being proposed here is neither more descriptive, nor more logical. In fact, it is an abandonment of description, in favour of arbitrary naming. A package called foo-1.0 containing a module hierarchy rooted at "Foo." tells me precisely nothing about its contents. It it were rooted at Military.Secret.Foo, at least I would have some clue about what it does, even if the category is inadequate or slightly misleading in certain circumstances. You may argue that only novices are disadvantaged by arbitrary names - once you learn the referent of the name, it is no longer confusing. However, I strongly believe that even experienced users are helped by the continuous re-inforcement of visual links between name and concept. After all, if you are collaboratively building a software artifact that depends on large numbers of library packages, it may not be so easy to keep your internal dictionary of the mapping between names and functionality up-to-date, and in sync with your colleagues. Being just a little bit more explicit in the hierarchy is a one-time cost at time of writing, that reaps perceptual benefits long into the future for yourself, and those maintainers who will follow you. Regards, Malcolm
Malcolm Wallace wrote:
Wolfgang Jeltsch <g9ks157k@acme.softbase.org> wrote:
The Yampa people and I (the Grapefruit maintainer) already agreed to introduce a top-level FRP namespace instead of putting FRP under Control or whatever.
The problem with a top-level namespace like FRP is that it is a cryptic acronym: it means nothing to a novice, and may be easily confused with other acronyms by an expert. I believe top-level names should _at_the_ _very_least_ be minimally descriptive of the category of things that live in it.
So, I'd be fine with Control.Reactive.FRP, Control.Reactive.Yampa, etc, or even just Reactive.Yampa etc.
Besides, it hardly seems necessary to emphasize "Functional" and "Programming" in the Haskell context...
Am Mittwoch, 17. Juni 2009 11:29 schrieb Anton van Straaten:
Malcolm Wallace wrote:
The problem with a top-level namespace like FRP is that it is a cryptic acronym: it means nothing to a novice, and may be easily confused with other acronyms by an expert. I believe top-level names should _at_the_ _very_least_ be minimally descriptive of the category of things that live in it.
So, I'd be fine with Control.Reactive.FRP, Control.Reactive.Yampa, etc, or even just Reactive.Yampa etc.
Besides, it hardly seems necessary to emphasize "Functional" and "Programming" in the Haskell context...
When we discussed where to place modules of FRP libraries in the hierarchy, it was argued that FRP had become a “brand”. It’s not just about programming reactive systems but describes a certain basic approach to it. Best wishes, Wolfgang
On 17/06/2009 10:05, Malcolm Wallace wrote:
Wolfgang Jeltsch<g9ks157k@acme.softbase.org> wrote:
The Yampa people and I (the Grapefruit maintainer) already agreed to introduce a top-level FRP namespace instead of putting FRP under Control or whatever.
The problem with a top-level namespace like FRP is that it is a cryptic acronym: it means nothing to a novice, and may be easily confused with other acronyms by an expert. I believe top-level names should _at_the_ _very_least_ be minimally descriptive of the category of things that live in it.
So, I'd be fine with Control.Reactive.FRP, Control.Reactive.Yampa, etc, or even just Reactive.Yampa etc.
I think this raises an interesting point. When we first started using hierarchical module names, we established a guiding principle: that the module name should reflect functionality first, so that the hierarchy can help you to find the functionality you're looking for. Including non-functionality-related information in module names should only be used to distinguish between multiple implementations of related functionality (e.g. Test.HUnit vs. Test.QuickCheck). That was before Hackage, which has largely taken over the role of helping users discover functionality. Obviously Hackage has a long way to go - it only has rudimentary categories right now, and in the past we've discussed having a more elaborate tagging scheme, but nevertheless Hackage seems like the right place to provide functionality-discovery. Before packages, there was a single module namespace shared by everyone. Now, for better or worse, there is a single package namespace shared by everyone, and the module namespace is essentially a free-for-all. Where does that leave module names? What are the advantages of having a rigidly-defined module hierarchy based on functionality classification? The only reasons I can think of are: * Choosing module names based on some generally agreed-upon guidelines makes it less likely that one package's module names will clash with another. * Packages that are conglomerations of different kinds of functionality (e.g. base) benefit from functionality-based module naming. * Source code doesn't refer to packages, it only refers to module names. So if you're trying to understand a piece of source code, it helps if the module names it imports are descriptive and unique. On the other hand, a module name tells you nothing of the provenance or the version of the module it refers to, so arguably source code without its dependencies is already less than useful. So why shouldn't OpenGL be naming its modules OpenGL.*, rather than Graphics.Rendering.OpenGL.*? Personally, I can't think of any sufficiently compelling reasons any more. Discuss! (replies set to libraries@haskell.org) Cheers, Simon
Am Mittwoch, 17. Juni 2009 11:05 schrieb Malcolm Wallace:
The problem with a top-level namespace like FRP is that it is a cryptic acronym: it means nothing to a novice, and may be easily confused with other acronyms by an expert. I believe top-level names should _at_the_ _very_least_ be minimally descriptive of the category of things that live in it.
So, I'd be fine with Control.Reactive.FRP, Control.Reactive.Yampa, etc, or even just Reactive.Yampa etc.
Where should the modules of Conal’s reactive package be rooted then? Under Control.Reactive.Reactive? Best wishes, Wolfgang
On Thu, Jun 18, 2009 at 06:03:03PM +0200, Wolfgang Jeltsch wrote:
Am Mittwoch, 17. Juni 2009 11:05 schrieb Malcolm Wallace:
The problem with a top-level namespace like FRP is that it is a cryptic acronym: it means nothing to a novice, and may be easily confused with other acronyms by an expert. I believe top-level names should _at_the_ _very_least_ be minimally descriptive of the category of things that live in it.
So, I'd be fine with Control.Reactive.FRP, Control.Reactive.Yampa, etc, or even just Reactive.Yampa etc.
Where should the modules of Conal’s reactive package be rooted then? Under Control.Reactive.Reactive?
I don't know anything about the package, but if putting the modules directly under Control.Reactive wouldn't make sense then it sounds to me like the package name is poor (too generic). Thanks Ian
Am Freitag, 19. Juni 2009 21:35 schrieb Ian Lynagh:
So, I'd be fine with Control.Reactive.FRP, Control.Reactive.Yampa, etc, or even just Reactive.Yampa etc.
Where should the modules of Conal’s reactive package be rooted then? Under Control.Reactive.Reactive?
I don't know anything about the package, but if putting the modules directly under Control.Reactive wouldn't make sense then it sounds to me like the package name is poor (too generic).
reactive is a specific FRP implementation by Conal Elliott. So it shouldn’t be put directly under Control.Reactive since other reasonable FRP implementations exist. Best wishes, Wolfgang
On Fri, Jun 12, 2009 at 2:24 AM, Sven Panne <Sven.Panne@aedion.de> wrote:
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.
Clay Shirky's points in include that this "sometimes" is more like "nearly always", and that the heart of the problem is "the" in "the position" (in a hierarchy). This problem and others discussed at http://www.shirky.com/writings/ontology_overrated.html . I have e.g. never fully understood why "Monad" and "Applicative" are below
"Control", but "Foldable" is below "Data"...
Monoid as well. Type classes in general cut across distinctions like Control and Data, so I don't think we'll ever have a comfortable place to put them in the existing hierarchy. If anything, I recommend the top-level name "Class". - Conal
Am Donnerstag, 11. Juni 2009 19:23:17 schrieb Bryan O'Sullivan:
[...] I think that "Graphics.Rendering." is clutter, and "OpenGL.GL." seems redundant to me. [...]
I forgot to mention one thing here: "OpenGL.GL" is currently *not* redundant, there is "OpenGL.GLU" in the OpenGL package, too. GL and GLU are separate libraries, even living in separate DLLs/*.sos, having separate headers, etc., so they should be kept separate in Haskell at some level, too. Nevertheless, with OpenGL 3.1 GLU is dead, anyway, so in future versions there will be no ".GL" part in the package names. Cheers, S.
participants (11)
-
Anton van Straaten -
Ashley Yakeley -
Bryan O'Sullivan -
Conal Elliott -
Ian Lynagh -
kahl＠cas.mcmaster.ca -
Malcolm Wallace -
Peter Verswyvelen -
Simon Marlow -
Sven Panne -
Wolfgang Jeltsch