This one pulls in Postgres. I still have to decide on how to persist data, will probably ask around in the SocialHub thread quite soon.
Note to self for further reading: https://www.haskelltutorials.com/odd-jobs/haskell-job-queues-ultimate-guide.html
The DHT layer also needs to schedule regular maintenance jobs, but as those won't pile up such an asynchronous background processing worker queue isn't necessary.
I'll take care of this at the next larger feature branch merge.
Can you point to some examples for this convention? The Main.hs didn't always reside in src/, but I moved it there after looking at other packages (I guess pandoc was one of those).
b8eeb852da
Merge pull request 'Linting integration' (#17) from Hecate/Hash2Pub:hlint-configuration into master
b8eeb852da
Merge pull request 'Linting integration' (#17) from Hecate/Hash2Pub:hlint-configuration into master
Thanks for these opinionated insights, they're a good starting point for Haskell newbies like me.
I need some clarifications though:
- Import lines ordering;
Regarding the imports, I am of the school that says “non-local imports are noise, put them on top, and keep the local imports as close as your code as possible”.
So you're basically recommending to put imports of haskell platform and other libraries first, and the module imports from the same package should appear last? I already tried to follow that rule, but may not have been consistent.
What is the import oordering you suggest? base ==> haskell-platform ==> package local imports?
- Preferring pure over return;
Why should pure be preferred over return in general? I always tried to use both of them depending on the context: When writing applicative-style functions, I used pure to make the applicative nature of the functions obvious, when messing around inside monads (e.g. with do notation) I used return to highlight the monad stuff, even when `pure could've been enough (example: Maybe).
