3 ms·

It foos a number into another number, what else? If it does something else or if it's unclear what fooing is, it should be renamed and the parameter types shoul

by pronik 10y ago

It foos a number into another number, what else? If it does something else or if it's unclear what fooing is, it should be renamed and the parameter types should be at least aliased to something more adjusted to the task. It's basically Haskell code smell. Other languages we are used to do not allow exact precision when talking about input and output types, that's why we don't think about overly-generic function declarations as smelly, but they are.

auggierose 10y ago
That's typical Haskell brain wash talk. Types can be a useful part of the documentation, but if your program is the least bit interesting, you will have parts that you should properly document. This is so much more true for libraries, especially those that adhere to a more mathematical style. If you write such a library, you should also write a paper explaining the library.
deleted 10y ago
[deleted]
icebraining 10y ago
Just out of curiosity, how would you change the following definition to make sure it's clear without reading anything else? words :: String -> [String] If you say it's already obvious, I disagree, since this code prints "1": main = print $ length $ words "jack am I" (The spaces in the string are six-per-em unicode characters)
- pronik 10y ago
  (like I said elsewhere, I'm a beginner, so I might be over-euphorical about controversial ideas. Also I don't in any way propose working only with type definitions instead of prosa documentation, however I think type definitions can go a long way to introduce the basic operations to the user) In this case, I'd try something like this: words :: Sentence -> [Word] (Sentence and Word being aliases for String) A function named `words` with `Sentence` as a parameter implies a common-sense do-what-I-mean function, like breaking on all sensible whitespace. With common sense in play, it's your task to make the function behave like people expect it to (which differs per person of course). If you choose not to, don't write `words`, write a `split` with a parameter for character classes (or indeed a boolean function working on a character) the split should be performed on. (PS. I assume you are implicitely critisizing Prelude's `words`, which breaks on anything that's `isSpace`, which is explicitely defined. Its definition is way out of my competence, there are probably good reasons for not including thin spaces. If not, they could probably get included with a due process -- with common sense, it's always an iterative process till it's done)

by pronik 10y ago

auggierose 10y ago

That's typical Haskell brain wash talk. Types can be a useful part of the documentation, but if your program is the least bit interesting, you will have parts that you should properly document. This is so much more true for libraries, especially those that adhere to a more mathematical style. If you write such a library, you should also write a paper explaining the library.

deleted 10y ago

[deleted]

icebraining 10y ago

Just out of curiosity, how would you change the following definition to make sure it's clear without reading anything else? words :: String -> [String] If you say it's already obvious, I disagree, since this code prints "1": main = print $ length $ words "jack am I" (The spaces in the string are six-per-em unicode characters)

pronik 10y ago
(like I said elsewhere, I'm a beginner, so I might be over-euphorical about controversial ideas. Also I don't in any way propose working only with type definitions instead of prosa documentation, however I think type definitions can go a long way to introduce the basic operations to the user) In this case, I'd try something like this: words :: Sentence -> [Word] (Sentence and Word being aliases for String) A function named `words` with `Sentence` as a parameter implies a common-sense do-what-I-mean function, like breaking on all sensible whitespace. With common sense in play, it's your task to make the function behave like people expect it to (which differs per person of course). If you choose not to, don't write `words`, write a `split` with a parameter for character classes (or indeed a boolean function working on a character) the split should be performed on. (PS. I assume you are implicitely critisizing Prelude's `words`, which breaks on anything that's `isSpace`, which is explicitely defined. Its definition is way out of my competence, there are probably good reasons for not including thin spaces. If not, they could probably get included with a due process -- with common sense, it's always an iterative process till it's done)