Is there any standard module / namespace naming convention in haskell?

Multi tool use
Multi tool use












10















I'm basically from python world and have been playing around with haskell for few days.



As an python user, namespaces of libraries from hackage / stackage was the most confusing.



For example, in python, we will import Scotty module like import scotty, while haskell will do import Web.Scotty.



Haskellers who upload their libraries on stackage or hackage seems to prefer putting their libraries under namespaces of a category (e.g. Web, Language, ...).



Leaving whether it's a good approach or not in perspective view of dependency control outside of discussion, is there any de-facto convention on this categorization?



Is there any community-consented guide like "Put these kind of libraries under Network category and put those kind of libraries under Web category or Data category." ?










share|improve this question




















  • 3





    haskell.org/cabal/proposal/x138.html tells us that "Each package has a globally-unique package name, containing no spaces. [...] How unique package names are handed out is not part of this specification [...]." but there is also wiki.haskell.org/Hierarchical_module_names

    – gxtaillon
    Nov 27 '15 at 4:36













  • I don't know if there's a written guide. I believe most developers choose the point in the current hackage hierarchy where the most similar libraries are found. Of course, exceptions exist: e.g. Web could have been Network.Web.

    – chi
    Nov 27 '15 at 8:47











  • Some languages (e.g. Java) prod the developers in using separate namespaces as in producer-name.a.b.c. In Haskell this convention is surely not followed: every package usually grafts its modules in the existing hierarchy.

    – chi
    Nov 27 '15 at 8:51
















10















I'm basically from python world and have been playing around with haskell for few days.



As an python user, namespaces of libraries from hackage / stackage was the most confusing.



For example, in python, we will import Scotty module like import scotty, while haskell will do import Web.Scotty.



Haskellers who upload their libraries on stackage or hackage seems to prefer putting their libraries under namespaces of a category (e.g. Web, Language, ...).



Leaving whether it's a good approach or not in perspective view of dependency control outside of discussion, is there any de-facto convention on this categorization?



Is there any community-consented guide like "Put these kind of libraries under Network category and put those kind of libraries under Web category or Data category." ?










share|improve this question




















  • 3





    haskell.org/cabal/proposal/x138.html tells us that "Each package has a globally-unique package name, containing no spaces. [...] How unique package names are handed out is not part of this specification [...]." but there is also wiki.haskell.org/Hierarchical_module_names

    – gxtaillon
    Nov 27 '15 at 4:36













  • I don't know if there's a written guide. I believe most developers choose the point in the current hackage hierarchy where the most similar libraries are found. Of course, exceptions exist: e.g. Web could have been Network.Web.

    – chi
    Nov 27 '15 at 8:47











  • Some languages (e.g. Java) prod the developers in using separate namespaces as in producer-name.a.b.c. In Haskell this convention is surely not followed: every package usually grafts its modules in the existing hierarchy.

    – chi
    Nov 27 '15 at 8:51














10












10








10


2






I'm basically from python world and have been playing around with haskell for few days.



As an python user, namespaces of libraries from hackage / stackage was the most confusing.



For example, in python, we will import Scotty module like import scotty, while haskell will do import Web.Scotty.



Haskellers who upload their libraries on stackage or hackage seems to prefer putting their libraries under namespaces of a category (e.g. Web, Language, ...).



Leaving whether it's a good approach or not in perspective view of dependency control outside of discussion, is there any de-facto convention on this categorization?



Is there any community-consented guide like "Put these kind of libraries under Network category and put those kind of libraries under Web category or Data category." ?










share|improve this question
















I'm basically from python world and have been playing around with haskell for few days.



As an python user, namespaces of libraries from hackage / stackage was the most confusing.



For example, in python, we will import Scotty module like import scotty, while haskell will do import Web.Scotty.



Haskellers who upload their libraries on stackage or hackage seems to prefer putting their libraries under namespaces of a category (e.g. Web, Language, ...).



Leaving whether it's a good approach or not in perspective view of dependency control outside of discussion, is there any de-facto convention on this categorization?



Is there any community-consented guide like "Put these kind of libraries under Network category and put those kind of libraries under Web category or Data category." ?







haskell






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Nov 27 '15 at 7:32







June

















asked Nov 27 '15 at 2:15









JuneJune

7062924




7062924








  • 3





    haskell.org/cabal/proposal/x138.html tells us that "Each package has a globally-unique package name, containing no spaces. [...] How unique package names are handed out is not part of this specification [...]." but there is also wiki.haskell.org/Hierarchical_module_names

    – gxtaillon
    Nov 27 '15 at 4:36













  • I don't know if there's a written guide. I believe most developers choose the point in the current hackage hierarchy where the most similar libraries are found. Of course, exceptions exist: e.g. Web could have been Network.Web.

    – chi
    Nov 27 '15 at 8:47











  • Some languages (e.g. Java) prod the developers in using separate namespaces as in producer-name.a.b.c. In Haskell this convention is surely not followed: every package usually grafts its modules in the existing hierarchy.

    – chi
    Nov 27 '15 at 8:51














  • 3





    haskell.org/cabal/proposal/x138.html tells us that "Each package has a globally-unique package name, containing no spaces. [...] How unique package names are handed out is not part of this specification [...]." but there is also wiki.haskell.org/Hierarchical_module_names

    – gxtaillon
    Nov 27 '15 at 4:36













  • I don't know if there's a written guide. I believe most developers choose the point in the current hackage hierarchy where the most similar libraries are found. Of course, exceptions exist: e.g. Web could have been Network.Web.

    – chi
    Nov 27 '15 at 8:47











  • Some languages (e.g. Java) prod the developers in using separate namespaces as in producer-name.a.b.c. In Haskell this convention is surely not followed: every package usually grafts its modules in the existing hierarchy.

    – chi
    Nov 27 '15 at 8:51








3




3





haskell.org/cabal/proposal/x138.html tells us that "Each package has a globally-unique package name, containing no spaces. [...] How unique package names are handed out is not part of this specification [...]." but there is also wiki.haskell.org/Hierarchical_module_names

– gxtaillon
Nov 27 '15 at 4:36







haskell.org/cabal/proposal/x138.html tells us that "Each package has a globally-unique package name, containing no spaces. [...] How unique package names are handed out is not part of this specification [...]." but there is also wiki.haskell.org/Hierarchical_module_names

– gxtaillon
Nov 27 '15 at 4:36















I don't know if there's a written guide. I believe most developers choose the point in the current hackage hierarchy where the most similar libraries are found. Of course, exceptions exist: e.g. Web could have been Network.Web.

– chi
Nov 27 '15 at 8:47





I don't know if there's a written guide. I believe most developers choose the point in the current hackage hierarchy where the most similar libraries are found. Of course, exceptions exist: e.g. Web could have been Network.Web.

– chi
Nov 27 '15 at 8:47













Some languages (e.g. Java) prod the developers in using separate namespaces as in producer-name.a.b.c. In Haskell this convention is surely not followed: every package usually grafts its modules in the existing hierarchy.

– chi
Nov 27 '15 at 8:51





Some languages (e.g. Java) prod the developers in using separate namespaces as in producer-name.a.b.c. In Haskell this convention is surely not followed: every package usually grafts its modules in the existing hierarchy.

– chi
Nov 27 '15 at 8:51












1 Answer
1






active

oldest

votes


















5














The package name, the package tags, and the module names are all independent things.



The package name is an arbitrary identifier (as long as it doesn't clash with anyone else). Its conventional to make it all lower case with hyphens between words. If several packages are part of a family then the format is e.g. "llvm-base" with the family name first. According to the Cabal manual package names can have letters, numbers and hyphens but not spaces. I don't know about any other punctuation, but I'd avoid it even if Cabal lets it through. Also thanks to the different rules about capital letters in pathnames between Windows and Linux there can be confusion, so its best to stick to lower case.



The tags are used to help sites like Hackage organise the list of packages into useful groups, and have no other significance.



Within a package will be one or more modules. These are what the client source code will import. Modules exist in a hierarchical name space. So for example the "parsec" package includes a module "Text.Parsec.Combinator". You can think of the dots as akin to Linux "/" in a path name (and in fact the source will be in a file at "src/Text/Parsec/Combinator.hs").



There are a few top-level conventional module names, such as "Control", "Data", "Text" and "System", which you can use according to the primary job of the module. Its good style to use them, but not obligatory. The appearance of the package name in the module name (e.g "Parsec") is only there to avoid name clashes; there is no formal relationship between the package name and the modules it holds.



It is quite possible to have a package with modules in different top-level hierarchies. For instance you might have a package containing "System.Foo" and "Data.Foo".



Broadly speaking "Control" is used for monads and related stuff, especially monadic and arrow combinators. But since a monad is also a data type you shouldn't feel the need to put a monadic type in a separate module just to get it into "Control".



"Data" is a catch-all. If in doubt, put it in Data.



"System" is used for operating system facilities, especially stuff that might not be portable.



"Text" is used for manipulating text, parsing, printing and so on. Anything with a lot of string manipulation probably belongs here.



"Graphics": obviously.



Its optional to have a module name at one level and then other modules below it. So "Text.Parsec" is a module, and so is "Text.Parsec.Combinators", but the designer of Parsec did not need to include "Text.Parsec". When this is done it usually means that the top level module (in this case "Text.Parsec") exports a common subset of its child modules, so in many cases the client code just needs to import "Text.Parsec" rather than the whole family.






share|improve this answer
























  • What about Numeric?

    – Dannyu NDos
    Jan 1 at 10:55











Your Answer






StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");

StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});

function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});


}
});














draft saved

draft discarded


















StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f33949401%2fis-there-any-standard-module-namespace-naming-convention-in-haskell%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown

























1 Answer
1






active

oldest

votes








1 Answer
1






active

oldest

votes









active

oldest

votes






active

oldest

votes









5














The package name, the package tags, and the module names are all independent things.



The package name is an arbitrary identifier (as long as it doesn't clash with anyone else). Its conventional to make it all lower case with hyphens between words. If several packages are part of a family then the format is e.g. "llvm-base" with the family name first. According to the Cabal manual package names can have letters, numbers and hyphens but not spaces. I don't know about any other punctuation, but I'd avoid it even if Cabal lets it through. Also thanks to the different rules about capital letters in pathnames between Windows and Linux there can be confusion, so its best to stick to lower case.



The tags are used to help sites like Hackage organise the list of packages into useful groups, and have no other significance.



Within a package will be one or more modules. These are what the client source code will import. Modules exist in a hierarchical name space. So for example the "parsec" package includes a module "Text.Parsec.Combinator". You can think of the dots as akin to Linux "/" in a path name (and in fact the source will be in a file at "src/Text/Parsec/Combinator.hs").



There are a few top-level conventional module names, such as "Control", "Data", "Text" and "System", which you can use according to the primary job of the module. Its good style to use them, but not obligatory. The appearance of the package name in the module name (e.g "Parsec") is only there to avoid name clashes; there is no formal relationship between the package name and the modules it holds.



It is quite possible to have a package with modules in different top-level hierarchies. For instance you might have a package containing "System.Foo" and "Data.Foo".



Broadly speaking "Control" is used for monads and related stuff, especially monadic and arrow combinators. But since a monad is also a data type you shouldn't feel the need to put a monadic type in a separate module just to get it into "Control".



"Data" is a catch-all. If in doubt, put it in Data.



"System" is used for operating system facilities, especially stuff that might not be portable.



"Text" is used for manipulating text, parsing, printing and so on. Anything with a lot of string manipulation probably belongs here.



"Graphics": obviously.



Its optional to have a module name at one level and then other modules below it. So "Text.Parsec" is a module, and so is "Text.Parsec.Combinators", but the designer of Parsec did not need to include "Text.Parsec". When this is done it usually means that the top level module (in this case "Text.Parsec") exports a common subset of its child modules, so in many cases the client code just needs to import "Text.Parsec" rather than the whole family.






share|improve this answer
























  • What about Numeric?

    – Dannyu NDos
    Jan 1 at 10:55
















5














The package name, the package tags, and the module names are all independent things.



The package name is an arbitrary identifier (as long as it doesn't clash with anyone else). Its conventional to make it all lower case with hyphens between words. If several packages are part of a family then the format is e.g. "llvm-base" with the family name first. According to the Cabal manual package names can have letters, numbers and hyphens but not spaces. I don't know about any other punctuation, but I'd avoid it even if Cabal lets it through. Also thanks to the different rules about capital letters in pathnames between Windows and Linux there can be confusion, so its best to stick to lower case.



The tags are used to help sites like Hackage organise the list of packages into useful groups, and have no other significance.



Within a package will be one or more modules. These are what the client source code will import. Modules exist in a hierarchical name space. So for example the "parsec" package includes a module "Text.Parsec.Combinator". You can think of the dots as akin to Linux "/" in a path name (and in fact the source will be in a file at "src/Text/Parsec/Combinator.hs").



There are a few top-level conventional module names, such as "Control", "Data", "Text" and "System", which you can use according to the primary job of the module. Its good style to use them, but not obligatory. The appearance of the package name in the module name (e.g "Parsec") is only there to avoid name clashes; there is no formal relationship between the package name and the modules it holds.



It is quite possible to have a package with modules in different top-level hierarchies. For instance you might have a package containing "System.Foo" and "Data.Foo".



Broadly speaking "Control" is used for monads and related stuff, especially monadic and arrow combinators. But since a monad is also a data type you shouldn't feel the need to put a monadic type in a separate module just to get it into "Control".



"Data" is a catch-all. If in doubt, put it in Data.



"System" is used for operating system facilities, especially stuff that might not be portable.



"Text" is used for manipulating text, parsing, printing and so on. Anything with a lot of string manipulation probably belongs here.



"Graphics": obviously.



Its optional to have a module name at one level and then other modules below it. So "Text.Parsec" is a module, and so is "Text.Parsec.Combinators", but the designer of Parsec did not need to include "Text.Parsec". When this is done it usually means that the top level module (in this case "Text.Parsec") exports a common subset of its child modules, so in many cases the client code just needs to import "Text.Parsec" rather than the whole family.






share|improve this answer
























  • What about Numeric?

    – Dannyu NDos
    Jan 1 at 10:55














5












5








5







The package name, the package tags, and the module names are all independent things.



The package name is an arbitrary identifier (as long as it doesn't clash with anyone else). Its conventional to make it all lower case with hyphens between words. If several packages are part of a family then the format is e.g. "llvm-base" with the family name first. According to the Cabal manual package names can have letters, numbers and hyphens but not spaces. I don't know about any other punctuation, but I'd avoid it even if Cabal lets it through. Also thanks to the different rules about capital letters in pathnames between Windows and Linux there can be confusion, so its best to stick to lower case.



The tags are used to help sites like Hackage organise the list of packages into useful groups, and have no other significance.



Within a package will be one or more modules. These are what the client source code will import. Modules exist in a hierarchical name space. So for example the "parsec" package includes a module "Text.Parsec.Combinator". You can think of the dots as akin to Linux "/" in a path name (and in fact the source will be in a file at "src/Text/Parsec/Combinator.hs").



There are a few top-level conventional module names, such as "Control", "Data", "Text" and "System", which you can use according to the primary job of the module. Its good style to use them, but not obligatory. The appearance of the package name in the module name (e.g "Parsec") is only there to avoid name clashes; there is no formal relationship between the package name and the modules it holds.



It is quite possible to have a package with modules in different top-level hierarchies. For instance you might have a package containing "System.Foo" and "Data.Foo".



Broadly speaking "Control" is used for monads and related stuff, especially monadic and arrow combinators. But since a monad is also a data type you shouldn't feel the need to put a monadic type in a separate module just to get it into "Control".



"Data" is a catch-all. If in doubt, put it in Data.



"System" is used for operating system facilities, especially stuff that might not be portable.



"Text" is used for manipulating text, parsing, printing and so on. Anything with a lot of string manipulation probably belongs here.



"Graphics": obviously.



Its optional to have a module name at one level and then other modules below it. So "Text.Parsec" is a module, and so is "Text.Parsec.Combinators", but the designer of Parsec did not need to include "Text.Parsec". When this is done it usually means that the top level module (in this case "Text.Parsec") exports a common subset of its child modules, so in many cases the client code just needs to import "Text.Parsec" rather than the whole family.






share|improve this answer













The package name, the package tags, and the module names are all independent things.



The package name is an arbitrary identifier (as long as it doesn't clash with anyone else). Its conventional to make it all lower case with hyphens between words. If several packages are part of a family then the format is e.g. "llvm-base" with the family name first. According to the Cabal manual package names can have letters, numbers and hyphens but not spaces. I don't know about any other punctuation, but I'd avoid it even if Cabal lets it through. Also thanks to the different rules about capital letters in pathnames between Windows and Linux there can be confusion, so its best to stick to lower case.



The tags are used to help sites like Hackage organise the list of packages into useful groups, and have no other significance.



Within a package will be one or more modules. These are what the client source code will import. Modules exist in a hierarchical name space. So for example the "parsec" package includes a module "Text.Parsec.Combinator". You can think of the dots as akin to Linux "/" in a path name (and in fact the source will be in a file at "src/Text/Parsec/Combinator.hs").



There are a few top-level conventional module names, such as "Control", "Data", "Text" and "System", which you can use according to the primary job of the module. Its good style to use them, but not obligatory. The appearance of the package name in the module name (e.g "Parsec") is only there to avoid name clashes; there is no formal relationship between the package name and the modules it holds.



It is quite possible to have a package with modules in different top-level hierarchies. For instance you might have a package containing "System.Foo" and "Data.Foo".



Broadly speaking "Control" is used for monads and related stuff, especially monadic and arrow combinators. But since a monad is also a data type you shouldn't feel the need to put a monadic type in a separate module just to get it into "Control".



"Data" is a catch-all. If in doubt, put it in Data.



"System" is used for operating system facilities, especially stuff that might not be portable.



"Text" is used for manipulating text, parsing, printing and so on. Anything with a lot of string manipulation probably belongs here.



"Graphics": obviously.



Its optional to have a module name at one level and then other modules below it. So "Text.Parsec" is a module, and so is "Text.Parsec.Combinators", but the designer of Parsec did not need to include "Text.Parsec". When this is done it usually means that the top level module (in this case "Text.Parsec") exports a common subset of its child modules, so in many cases the client code just needs to import "Text.Parsec" rather than the whole family.







share|improve this answer












share|improve this answer



share|improve this answer










answered Nov 27 '15 at 18:28









Paul JohnsonPaul Johnson

13.6k23449




13.6k23449













  • What about Numeric?

    – Dannyu NDos
    Jan 1 at 10:55



















  • What about Numeric?

    – Dannyu NDos
    Jan 1 at 10:55

















What about Numeric?

– Dannyu NDos
Jan 1 at 10:55





What about Numeric?

– Dannyu NDos
Jan 1 at 10:55




















draft saved

draft discarded




















































Thanks for contributing an answer to Stack Overflow!


  • Please be sure to answer the question. Provide details and share your research!

But avoid



  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.


To learn more, see our tips on writing great answers.




draft saved


draft discarded














StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f33949401%2fis-there-any-standard-module-namespace-naming-convention-in-haskell%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown





















































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown

































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown







u6Q Uktfq,ceMFQ35jfKcOS42bbR3 vEpXbqNAyTn5,SNiUj
I MnBkLP tDA Gf,cKS4ZT7nwY8 2uH,77JNH7 94A40r6l68b9Q6P IelutHDay

Popular posts from this blog

Monofisismo

Angular Downloading a file using contenturl with Basic Authentication

Olmecas