Re: [Haskell-cafe] Graphics.Drawing
On Sep 6, 2010, at 1:57 PM, han wrote: So the question is: Do you agree that Graphics.Rendering.OpenGL actually should have been Graphics.OpenGL (or just OpenGL) for wieldiness? If you don't, what is your reason? I would like to know. Often, when this topic comes up, someone claims that ontology is overrated [1]. This time it's me. Sebastian [1]: http://www.shirky.com/writings/ontology_overrated.html -- Underestimating the novelty of the future is a time-honored tradition. (D.G.) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Graphics.Drawing
On 6 September 2010 21:57, han e...@xtendo.org wrote: So the question is: Do you agree that Graphics.Rendering.OpenGL actually should have been Graphics.OpenGL (or just OpenGL) for wieldiness? I think Graphics.OpenGL would have sufficed, unless there was sufficient reason to want to group it with other rendering-specific modules. Admittedly, I'm biased, in that I proposed a new top-level Graph.* namespace on the libraries mailing list and out of those few that responded the main response was that there was no point in such a new top-level namespace. -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Graphics.Drawing
On Mon, Sep 6, 2010 at 5:29 AM, Ivan Lazar Miljenovic ivan.miljeno...@gmail.com wrote: On 6 September 2010 21:57, han e...@xtendo.org wrote: So the question is: Do you agree that Graphics.Rendering.OpenGL actually should have been Graphics.OpenGL (or just OpenGL) for wieldiness? I think Graphics.OpenGL would have sufficed, unless there was sufficient reason to want to group it with other rendering-specific modules. I'm relatively new to the Haskell community, and one thing that's bugged me a bit is that there doesn't seem to be a convention (aside from common sense) for segmenting the module namespace as there is with Java (my other primary language). If you're not familiar with Java's conventions: Each package producer is encouraged to prefix all their released packages with a reversed dns name (more or less, I don't recall the exact term). For example, if Galois were to release a Java OpenGL package, it would be named something like com.galois.graphics.opengl. This makes it fairly easy to differentiate between different implementations of similar things -- or just to reduce namespace collisions. This comes at the expense of typing a bit more, but no one particularly cares in the java community because the IDEs take care of that. Anyway, I'm curious how module namespace collisions/pollution will be handled in Haskell over the next 5-10 years. Package hiding works in some cases, but it seems like that will fail if you ever need to use capabilities from packages that conflict within the same project. Is this actually a problem, or am I worried about nothing? --Rogan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Graphics.Drawing
creswick: On Mon, Sep 6, 2010 at 5:29 AM, Ivan Lazar Miljenovic ivan.miljeno...@gmail.com wrote: On 6 September 2010 21:57, han e...@xtendo.org wrote: So the question is: Do you agree that Graphics.Rendering.OpenGL actually should have been Graphics.OpenGL (or just OpenGL) for wieldiness? I think Graphics.OpenGL would have sufficed, unless there was sufficient reason to want to group it with other rendering-specific modules. I'm relatively new to the Haskell community, and one thing that's bugged me a bit is that there doesn't seem to be a convention (aside from common sense) for segmenting the module namespace as there is with Java (my other primary language). Anyway, I'm curious how module namespace collisions/pollution will be handled in Haskell over the next 5-10 years. Package hiding works in some cases, but it seems like that will fail if you ever need to use capabilities from packages that conflict within the same project. Well, we have a single global namespace for some 30k modules on Hackage. People are encouraged to partition their packages via top level names, such as Control.* or System.* An tree structure that is roughly followed, http://haskell.org/haskellwiki/Hierarchical_module_names However, when this was planned, I don't think we expected to go from 100 modules to 30k modules in 4 years, and there's been little work on thinking about how to structure the module system at this scale, other than work on explicit package naming and versioning. -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Graphics.Drawing
On 6 September 2010 10:09, han e...@xtendo.org wrote: I think there should be Graphics.Drawing (along with Graphics.Rendering) and many graphics packages should go into it. Why? So * Graphics.Rendering will contain more technical and rendering-engine-level packages (OpenGL, GD, ...) * while Graphics.Drawing will be for higher-level and user-friendlier drawing tools. (gloss, graphics-drawingcombinators, hieroglyph, Chart, ...) Currently most graphics packages are thrown into Graphics.Rendering or even Graphics. I think we all agree that having a standalone package right under Graphics is undesirable. Why is it undesirable? Henning Thielmann's gnuplot package for example uses Graphics.Gnuplot.*. Whilst we could make that Graphics.Plotting.Gnuplot.*, the module names are getting a little unwieldy then. There needs to be at least one subcategory. (which is why I also think Win32 and X11 should be moved from Graphics to Graphics.UI.) What do you think? I fail to see a reason for this (well, I can see why it might be desirable from an hierarchical point of view, but not how it will help from a usage point of view since we don't really look for packages based upon the module hierarchy but rather on package name, descriptions and categories on Hackage). -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
