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

Multi tool use
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
add a comment |
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
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 beenNetwork.Web
.
– chi
Nov 27 '15 at 8:47
Some languages (e.g. Java) prod the developers in using separate namespaces as inproducer-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
add a comment |
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
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
haskell
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 beenNetwork.Web
.
– chi
Nov 27 '15 at 8:47
Some languages (e.g. Java) prod the developers in using separate namespaces as inproducer-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
add a comment |
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 beenNetwork.Web
.
– chi
Nov 27 '15 at 8:47
Some languages (e.g. Java) prod the developers in using separate namespaces as inproducer-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
add a comment |
1 Answer
1
active
oldest
votes
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.
What aboutNumeric
?
– Dannyu NDos
Jan 1 at 10:55
add a comment |
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
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
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.
What aboutNumeric
?
– Dannyu NDos
Jan 1 at 10:55
add a comment |
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.
What aboutNumeric
?
– Dannyu NDos
Jan 1 at 10:55
add a comment |
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.
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.
answered Nov 27 '15 at 18:28
Paul JohnsonPaul Johnson
13.6k23449
13.6k23449
What aboutNumeric
?
– Dannyu NDos
Jan 1 at 10:55
add a comment |
What aboutNumeric
?
– 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
add a comment |
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.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
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
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 beenNetwork.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