this post was submitted on
1 point (53% like it)
8 up votes 7 down votes
shortlink:
to anything interesting: news article, blog entry, video, picture...

0
1

Removing my Data. prefix (self.haskell)

submitted ago by roconnor

sorry, this has been archived and can no longer be voted on

I am thinking of renaming my Data.Colour module to be simply Colour. The Data. prefix doesn't seem to provide anything useful. Furthermore I think that removing the Data. prefix would make

import qualified Colour

more useful.

Hackage upload warns about uploading things outside the Data.* etc. hierarchy. What is the reasoning behind this?

Note: Comments about the spelling of Colour will be downvoted. It is off topic and a never ending discussion.

all 27 comments
sorted by:
best
hot
new
controversial
top
old

[–]yitz 6 points7 points ago

sorry, this has been archived and can no longer be voted on

Please don't do that. In general, hierarchies with too many root nodes are fragmented and unmanageable. For example, you will ruin the party for those who want to navigate the Haddock tree by starting with a simple, fully-collapsed tree and drilling down. Yes, there are other navigation methods that would not be affected, but why make this mess in the first place?

It is analogous to putting all of your directories off the root of your Unix file system. True, modern FSes might not drag down your system performance anymore if you do that. And true, there are Unixy tools like "locate" and "find". But - why make this mess in the first place?

[–]roconnor[S] 4 points5 points ago

sorry, this has been archived and can no longer be voted on

For example, you will ruin the party for those who want to navigate the Haddock tree by starting with a simple, fully-collapsed tree and drilling down.

But they get the same mess as soon as they open up Data.. I don't see how making them press one button before seeing a mess helps anyone. Worse even, one could end up looking through all of Data. before you find out it isn't there and you have to start all over again with Control..

[–]yairchu 2 points3 points ago

sorry, this has been archived and can no longer be voted on

the specific example of "Colour" doesn't belong in Control.

[–]yitz 1 point2 points ago

sorry, this has been archived and can no longer be voted on

Right, you probably shouldn't put it directly under Data, either. It should be even further down the hierarchy. You didn't provide a link, so I don't know exactly what this module is supposed to do.

[–]roconnor[S] 0 points1 point ago

sorry, this has been archived and can no longer be voted on

For what it is worth: http://hackage.haskell.org/package/colour

[–]Peaker 1 point2 points ago

sorry, this has been archived and can no longer be voted on

If they press Network, and not Data, they don't get that mess.

[–]almafa 4 points5 points ago

sorry, this has been archived and can no longer be voted on

By the same logic, at least 50 other packages could remove the prefix, and then the top-level would be extremely cluttered. The current ad-hoc solution is in serious need of revamping, I agree with full heart, but this sounds like a very bad idea. (I also agree that Data is overused).

[–]dons 4 points5 points ago

sorry, this has been archived and can no longer be voted on

Please don't pick a new tiny part of the top level namespace. This makes it hard to categorize your package using automated tools.

[–]roconnor[S] 4 points5 points ago

sorry, this has been archived and can no longer be voted on

How does sticking Data. or Control. in front of everything help?

[–]edwardkmett 3 points4 points ago* 

sorry, this has been archived and can no longer be voted on

It helps, just not enough.

One might argue that Colour is a specific enough concept to image processing, graphics and UI design, that it belongs under the existing Graphics namespace as something like Graphics.Colour. This would get you out of the cesspool that is the root of Data.

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

In the end, the existence of the hierarchical namespaces is a bikeshedding issue, but it is one, kind of like the package versioning policy, that works best if everyone follows the same general standard.

[–]jkff 3 points4 points ago

sorry, this has been archived and can no longer be voted on

Oh yes, Graphics.Colour seems the solution to me. (although I've never used the package :) )

[–]roconnor[S] 2 points3 points ago* 

sorry, this has been archived and can no longer be voted on

I didn't put it into Graphics. because the main module and datatype of colour is in principle physiological rather than graphical. I do admit that in practice many of the submodules (particularly sRGB) are graphics related ... hmm.

[–]roconnor[S] 0 points1 point ago* 

sorry, this has been archived and can no longer be voted on

It helps, just not enough.

I'm slowly coming around to the opinion that the module/package system needs some fixing along the lines of the thread that I mentioned. Dropping the Data. prefix is insufficient, at least without a change in the general module/package system.

[–]edwardkmett 1 point2 points ago

sorry, this has been archived and can no longer be voted on

I read the thread in question, and I loved wren's suggestion as to how you could build package-local namespaces, but it sounds like it would be severely invasive to all sorts of things inside of GHC. I am considering a very similar approach for my own toy language project, having seen the general growing pains of the existing Haskell hierarchical namespaces, however.

[–]geezusfreeek 4 points5 points ago

sorry, this has been archived and can no longer be voted on

http://www.shirky.com/writings/ontology_overrated.html

[–]yitz 2 points3 points ago

sorry, this has been archived and can no longer be voted on

Shirky's essay is highly overrated.

Well, at least it is now. At the time that he wrote it, ontologies were all the rage. Some people thought they would somehow provide a magical AI solution to every information management problem.

But now, partially under the influence of Shirky's essay, the pendulum has swung too far the other way. Ontologies are indeed useful and powerful. Not perfect, usually far from a complete solution, but very worthwhile.

[–]geezusfreeek 3 points4 points ago

sorry, this has been archived and can no longer be voted on

I do agree that ontologies are not useless. However, I find it instructive to consider how I (and I assume most of us?) find packages on Hackage. I go to the big list of organized packages with the list of categories at the top that link to sections on the page, ignore all that, and use Firefox's in-page search.

[–]mwotton 5 points6 points ago

sorry, this has been archived and can no longer be voted on

isn't "import qualified Data.Colour as Colour" the same thing?

[–]roconnor[S] 1 point2 points ago

sorry, this has been archived and can no longer be voted on

Yes, but import qualified Colour is less verbose.

[–]Peaker 6 points7 points ago

sorry, this has been archived and can no longer be voted on

I don't think one should be too bothered about the verbosity of the import statements.

[–]hiker 2 points3 points ago

sorry, this has been archived and can no longer be voted on

Even beter: "import qualified Data.Colour as Color".

[–]yitz 4 points5 points ago

sorry, this has been archived and can no longer be voted on

Hey, hands off the bikeshed, OK?

[–]nnunley 2 points3 points ago

sorry, this has been archived and can no longer be voted on

But it needs to be blue!

[–]edwardkmett 1 point2 points ago* 

sorry, this has been archived and can no longer be voted on

I agree. Now you need to pick the color space. YCbCr, YCgCo, RGB, HSV... so many to choose from, so little time.

[–]yitz 0 points1 point ago

sorry, this has been archived and can no longer be voted on

In other words, don't post comments about what colo?r to paint the bikeshed.

[–]roconnor[S] 0 points1 point ago* 

sorry, this has been archived and can no longer be voted on

I just found this thread which might be relevant: Revamping the module hierarchy

[–]cdsmith 0 points1 point ago

sorry, this has been archived and can no longer be voted on

I think no one quite acknowledged the important point raised (by Igloo, I think? don't recall). Namely, hierarchical packages mean that someone looks for OpenGL doesn't need to look in the Network hierarchy. Yeah, sure there's some ambiguity, but that's not a fatal problem, since we're talking about human beings browsing API documentation. We aren't talking about trying to automate things. We're talking about trying to organize things by topic, acknowledging that there will necessarily be some overlap. Libraries have faced a similar problem for centuries, but they didn't give up and just arrange all the books alphabetically by title. If they did, they would be massively less useful.

Anyone looking at placing each package in a separate top-level module should go re-read statistics on how many new packages are uploaded to Hackage every week.

Use of this site constitutes acceptance of our User Agreement and Privacy Policy. © 2012 reddit inc. All rights reserved.

REDDIT and the ALIEN Logo are registered trademarks of reddit inc.

π Rendered by PID 15210 on app-87 running 24c540e.