Re: [HOpenGL] Re: [Haskell] ANNOUNCE: OpenGLRaw 1.0.0.0
On Fri, Jun 12, 2009 at 2:24 AM, Sven Panne 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 ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
RE: [Haskell] ANNOUNCE: OpenGLRaw 1.0.0.0
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-boun...@haskell.org [mailto:haskell-boun...@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 ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
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
Re: [Haskell] ANNOUNCE: OpenGLRaw 1.0.0.0
Sven Panne schrieb: 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, Are you sure? glu is mainly for converting an arbitrary polygon into triangles. This is an art and so obviously wasn't put into hardware or driver. From a previous post I remember that tesselation was mentioned. But looking at some presentation slides from AMD/ATI I understand that tesselation in directx11 is using the following primitive patches: Triangles and Tri-patches, Quads and Quad Patches, Lines and Line Patches, see http://ati.amd.com/developer/gdc/2008/Tatarchuk-Tessellation_GDC08.pdf slide 31. I haven't found a lot of information in the OpenGL 3.1 Spec, so I assume they will do it similar to directx11. So, if glu is still needed, until I use a better algorithm in my library. anyway, so in future versions there will be no ".GL" part in the package names. Cheers, S. ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] ANNOUNCE: OpenGLRaw 1.0.0.0
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. ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] ANNOUNCE: OpenGLRaw 1.0.0.0
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. ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] ANNOUNCE: OpenGLRaw 1.0.0.0
> > 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 ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] ANNOUNCE: OpenGLRaw 1.0.0.0
On Thu, Jun 11, 2009 at 9:56 AM, Sven Panne 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. ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] 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. ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
