Foo to Bar: Naming Conventions in Haskell
kowainik.github.io
Foo to Bar: Naming Conventions in Haskell
1–10 of 12 posts
Re: Foo to Bar: Naming Conventions in Haskell
#2This is a really nice guide and I like the suggestions at the end. One extra suggestion that would at least be great for me with Haskell is specializing the names of the super generic functions. Like there’s no reason to keep the function names “traversable” and “sequenceA” for your specific Traversable. It’s the same as type synonyms being useful because, while it’s the same thing, intent is clearer.
I love the Haskell for its focus on reusable pieces, but I can’t keep up when I have to learn and remember all of those pieces to learn that ‘monoEndoSequentialAlternataverse mEmpty (.)’ is just a getter from your nifty key value store.
Re: Foo to Bar: Naming Conventions in Haskell
#3I think the article implies a bit of a strict convention for the apostrophe (which is used as an ascii prime mark), as implying a strict version of the unprimed name. I think it’s usage is more general and just means something “similar but slightly different” to the unprimed name.
Re: Foo to Bar: Naming Conventions in Haskell
#4I always liked x, xs and xss ("x", "x's", "excesses") but never sure if I'd have "got" them had I not been taught them in person...
Re: Foo to Bar: Naming Conventions in Haskell
#5This is a really nice guide and I like the suggestions at the end. One extra suggestion that would at least be great for me with Haskell is specializing the names of the super generic functions. Like there’s no reason to keep the function names “traversable” and “sequenceA” for your specific Traversable. It’s the same as type synonyms being useful because, while it’s the same thing, intent is clearer. I love the Hask…
Here's what I do, for example:
import qualified Data.List as DL
import qualified Data.Map.Strict as DMS
You can also create your own functions as synonyms, if you feel like, it's easy and compiler has no issue with that. I often do that for structures (defined with "type") that I use in a module, to increase legibility.
Finally, the record dot syntax is becoming accepted to Haskell, it might help in writing IDEs that suggest methods based on types. (Peyton Jones explained somewhere that it's one of the advantages of method syntax, that it helps to show available methods.)
Re: Foo to Bar: Naming Conventions in Haskell
#6This is a really nice guide and I like the suggestions at the end. One extra suggestion that would at least be great for me with Haskell is specializing the names of the super generic functions. Like there’s no reason to keep the function names “traversable” and “sequenceA” for your specific Traversable. It’s the same as type synonyms being useful because, while it’s the same thing, intent is clearer. I love the Hask…
Here's what I do, for example: import qualified Data.List as DL import qualified Data.Map.Strict as DMS and then in code, I use DL.foldl' or DMS.foldl' as needed. Not sure if that answers your question, though. (I also use classy-prelude, it's the best IMHO.) You can also create your own functions as synonyms, if you feel like, it's easy and compiler has no issue with that. I often do that for structures (defined wit…
While I know it is subjective, it is still my person pet-peeve. Abbreviations like DL and DMS are really hard to read and remember. What I would have used instead is List and Map.
Re: Foo to Bar: Naming Conventions in Haskell
#7this is the single most useful Haskell article I've seen
it is really nice to know there is some logic behind names like "liftA2" and ">"
before reading this they just seemed bafflingly arbitrary
Re: Foo to Bar: Naming Conventions in Haskell
#8Earlier quoted context omitted.
Here's what I do, for example: import qualified Data.List as DL import qualified Data.Map.Strict as DMS and then in code, I use DL.foldl' or DMS.foldl' as needed. Not sure if that answers your question, though. (I also use classy-prelude, it's the best IMHO.) You can also create your own functions as synonyms, if you feel like, it's easy and compiler has no issue with that. I often do that for structures (defined wit…
While I know it is subjective, it is still my person pet-peeve. Abbreviations like DL and DMS are really hard to read and remember. What I would have used instead is List and Map.
That's fine. I like to use these because they are visually distinct identifiers (and short), List and Map look like the type (class) names. I know it's a different namespace, but still..
Re: Foo to Bar: Naming Conventions in Haskell
#9Earlier quoted context omitted.
Here's what I do, for example: import qualified Data.List as DL import qualified Data.Map.Strict as DMS and then in code, I use DL.foldl' or DMS.foldl' as needed. Not sure if that answers your question, though. (I also use classy-prelude, it's the best IMHO.) You can also create your own functions as synonyms, if you feel like, it's easy and compiler has no issue with that. I often do that for structures (defined wit…
While I know it is subjective, it is still my person pet-peeve. Abbreviations like DL and DMS are really hard to read and remember. What I would have used instead is List and Map.
hlint rules are nice for enforcing this, eg. you put sg. like this in your .hlint.yaml:
- modules:
- { name: [Data.List], as: List }
- { name: [Data.Map, Data.Map.Strict], as: Map }
Re: Foo to Bar: Naming Conventions in Haskell
#10This is a really nice guide and I like the suggestions at the end. One extra suggestion that would at least be great for me with Haskell is specializing the names of the super generic functions. Like there’s no reason to keep the function names “traversable” and “sequenceA” for your specific Traversable. It’s the same as type synonyms being useful because, while it’s the same thing, intent is clearer. I love the Hask…
Here's what I do, for example: import qualified Data.List as DL import qualified Data.Map.Strict as DMS and then in code, I use DL.foldl' or DMS.foldl' as needed. Not sure if that answers your question, though. (I also use classy-prelude, it's the best IMHO.) You can also create your own functions as synonyms, if you feel like, it's easy and compiler has no issue with that. I often do that for structures (defined wit…
> You can also create your own functions as synonyms, if you feel like, it's easy and compiler has no issue with that.
This is specifically what was trying to suggest. I wish folks would do more of it. Write the synonym for your function and then a brief docstring about what it means for this specific case.
All the generic tooling means that writing your getter or whatever might be simpler than it is in another language, but it's still worth writing. Even when it's just a synonym.