According to http://www.haskell.org/hierarchical-modules/libraries/reference-libraries.ht... I'm supposed to ask here for bits of heirarchy. I have no idea if this is still the procedure. As far as I know nobody follows this procedure. But I could just be ignorant. :) I'd like Data.Colour for my colour package: http://hackage.haskell.org/package/colour I should point out that http://hackage.haskell.org/package/AC-Colour also used Data.Colour, so there is a conflict to be resolved here. -- Russell O'Connor http://r6.ca/ ``All talk about `theft,''' the general counsel of the American Graphophone Company wrote, ``is the merest claptrap, for there exists no property in ideas musical, literary or artistic, except as defined by statute.''
Sorry about the lack of subject. Here is a subject now. On Tue, 11 Aug 2009, roconnor@theorem.ca wrote:
According to http://www.haskell.org/hierarchical-modules/libraries/reference-libraries.ht... I'm supposed to ask here for bits of heirarchy. I have no idea if this is still the procedure. As far as I know nobody follows this procedure. But I could just be ignorant. :)
I'd like Data.Colour for my colour package: http://hackage.haskell.org/package/colour
I should point out that http://hackage.haskell.org/package/AC-Colour also used Data.Colour, so there is a conflict to be resolved here.
-- Russell O'Connor http://r6.ca/ ``All talk about `theft,''' the general counsel of the American Graphophone Company wrote, ``is the merest claptrap, for there exists no property in ideas musical, literary or artistic, except as defined by statute.''
On Tue, Aug 11, 2009 at 08:33:24PM -0400, roconnor@theorem.ca wrote:
According to http://www.haskell.org/hierarchical-modules/libraries/reference-libraries.ht... I'm supposed to ask here for bits of heirarchy. I have no idea if this is still the procedure. As far as I know nobody follows this procedure. But I could just be ignorant. :)
I'd like Data.Colour for my colour package: http://hackage.haskell.org/package/colour
I should point out that http://hackage.haskell.org/package/AC-Colour also used Data.Colour, so there is a conflict to be resolved here.
I think that if there is a package called "colour", then it should be the one to provide Data.Colour. I don't have any opinion on whether that should be your package, AC's package, or neither (as I haven't really looked at either of them). Maybe this should be decided by whatever process we end up with for Haskell Platform inclusion? Thanks Ian
Hello,
I know the the Haskell Platform is in the spot-light at the moment but
please do not mix it in into name conventions as well! Different
packages can provide modules with the same name, so it seems perfectly
reasonable to let programmers choose the names for their modules.
-Iavor
PS: Having lived in the US for a while I would prefer Color to Colour
but obviously that is not particularly important.
On Thu, Aug 13, 2009 at 7:39 PM, Ian Lynagh
On Tue, Aug 11, 2009 at 08:33:24PM -0400, roconnor@theorem.ca wrote:
According to http://www.haskell.org/hierarchical-modules/libraries/reference-libraries.ht... I'm supposed to ask here for bits of heirarchy. I have no idea if this is still the procedure. As far as I know nobody follows this procedure. But I could just be ignorant. :)
I'd like Data.Colour for my colour package: http://hackage.haskell.org/package/colour
I should point out that http://hackage.haskell.org/package/AC-Colour also used Data.Colour, so there is a conflict to be resolved here.
I think that if there is a package called "colour", then it should be the one to provide Data.Colour.
I don't have any opinion on whether that should be your package, AC's package, or neither (as I haven't really looked at either of them). Maybe this should be decided by whatever process we end up with for Haskell Platform inclusion?
Thanks Ian
_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries
On Fri, Aug 14, 2009 at 08:28:54AM -0400, Iavor Diatchki wrote:
Hello, I know the the Haskell Platform is in the spot-light at the moment but please do not mix it in into name conventions as well! Different packages can provide modules with the same name, so it seems perfectly reasonable to let programmers choose the names for their modules.
But it is then impossible (apart from with a non-portable GHC extension) to use both packages in one program/library. It will also cause confusion. Thanks Ian
On Fri, Aug 14, 2009 at 1:38 PM, Ian Lynagh
On Fri, Aug 14, 2009 at 08:28:54AM -0400, Iavor Diatchki wrote:
Hello, I know the the Haskell Platform is in the spot-light at the moment but please do not mix it in into name conventions as well! Different packages can provide modules with the same name, so it seems perfectly reasonable to let programmers choose the names for their modules.
But it is then impossible (apart from with a non-portable GHC extension) to use both packages in one program/library.
It will also cause confusion.
Naming and avoiding name collisions are important. However I think this is best dealt with on a case-by-case basis. I'm happy to have a complete wild-west mentality to naming outside HP... of course the astute Haskell developer would quickly realise that it's fraught with problems to create name collisions with packages already in HP and it would preclude inclusion in HP as well. /M -- Magnus Therning (OpenPGP: 0xAB4DFBA4) magnus＠therning．org Jabber: magnus＠therning．org http://therning.org/magnus identi.ca|twitter: magthe
On Fri, 14 Aug 2009, Iavor Diatchki wrote:
Different packages can provide modules with the same name, so it seems perfectly reasonable to let programmers choose the names for their modules.
What you say here seems to be somewhat at odds with what is written in the below documentation: http://www.haskell.org/hierarchical-modules/libraries/reference-libraries.ht... Specifically where it says: ``If, however, you are providing a library for any other part of the hierarchy [not in User or Org], then the module names in the should be allocated.'' Your disagreement might be okay. This documentation is quite old, and might be out of date. However, if this is the case then might I suggest it either be removed from haskell.org or somehow marked as being obsolete. -- Russell O'Connor http://r6.ca/ ``All talk about `theft,''' the general counsel of the American Graphophone Company wrote, ``is the merest claptrap, for there exists no property in ideas musical, literary or artistic, except as defined by statute.''
On 14/08/2009 17:07, roconnor@theorem.ca wrote:
On Fri, 14 Aug 2009, Iavor Diatchki wrote:
Different packages can provide modules with the same name, so it seems perfectly reasonable to let programmers choose the names for their modules.
What you say here seems to be somewhat at odds with what is written in the below documentation:
http://www.haskell.org/hierarchical-modules/libraries/reference-libraries.ht...
Specifically where it says:
``If, however, you are providing a library for any other part of the hierarchy [not in User or Org], then the module names in the should be allocated.''
Your disagreement might be okay. This documentation is quite old, and might be out of date. However, if this is the case then might I suggest it either be removed from haskell.org or somehow marked as being obsolete.
That document is quite out of date, I've now removed it to avoid confusion. There are no official policies regarding module namespace now. You can upload a package to Hackage containing whatever module names you like. However, if you choose modules that overlap with another package, then users will have some difficulty in using both packages together (not necessarily a showstopper). If you choose silly module names, that's a a library design issue in the same way that choosing silly function names would be. We really ought to have some good coding style guidelines that include how to choose module names. Cheers, Simon
participants (5)
-
Ian Lynagh -
Iavor Diatchki -
Magnus Therning -
roconnor＠theorem.ca -
Simon Marlow