I haven't set it up as a pre-commit hook yet as I don't fully understand it, but running it manually before a commit does only complain about unclean working state.
Then maybe the workflow of this script isn't suited for you. Which editor are you using?
Do you mean that I then manually shall invoke stylish-haskell -i on each Haskell file in the repo? Couldn't I just let the pre-commit script make that do automatically,
NOPE! If you do so, stylish-haskell will edit the files in-place, then return the return code 0, then you'll be prompted to enter the commit's message, which won't include the edited files, because you couldn't add them in the meantime. Basically, you'll have to commit a fixup afterwards.
syntax errors, incomplete implementations)
stylish-haskell will most definitely stumble on syntax errors. My vim bindings apply it each time I save the file, so it gets formatted in-place.
If run as a pre-commit hook, wouldn't it always complain about a dirty working directory then as before a commit changes aren't commited yet?
It will! Sorry for the confusion 😵
What I meant to say is that the script uses the in-place editing feature of stylish-haskell to then detect files that need to be passed through by checking the git status of those files (since they were edited by stylish-haskell, they are now unstaged).
But the important thing here is that since it returns 1 as an exit code, it will abort the commit step and let you apply stylish-haskell on the incriminated files.
Am I clear enough? I haven't had much sleep recently…
@hecate I do not fully understand what's the best way of using
stylish-haskellin my workflow:
I have an editor plugin that calls it for the current buffer that I am saving.
The helper script can be run in a CI action or a pre-commit git hook (very useful, I also use that for hlint).
I personally think Postgres is far from being "overkill" if you are going to build some kind of highly-connected network service, especially if you wish to do some retention. Of course it's not like sqlite3, but it's a fairly standard tool on the "engineering" side of things. :)
@schmittlauch If you wish to use one of the best and full-featured libraries on Hackage, I can only recommend odd-jobs.
Yes, Pandoc, with some other high-profile stuff, have always done things "their own way" for quite some time. :)
Regarding more “pedestrian” open-source projects, I can point to mini-lambda, top-apps, causal-haskell. Unfortunately I can't really point you to the closed-source projects I had the opportunity to work on, so you'll have to believe me on those. :P
b8eeb852da
Merge pull request 'Linting integration' (#17) from Hecate/Hash2Pub:hlint-configuration into master
What is the import oordering you suggest?
Two separated blocks for non-hash2pub modules and hash2pub modules. Whether or not they belong to the Haskell platform is irrelevant: They will get ordered alphabetically whilst staying in their lane.
See:
import Control.Monad
import Data.Time
import Hash2Pub.ASN1Coding
import Hash2Pub.FediChord
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
purecould've been enough (example: Maybe).
This is an interesting point, and I see why you do that. However, there are two benefits, on two different dimensions, for preferring pure to return:
returnhas a strong, strong history of being a keyword in imperative languages to send back the value produced by the function, and this semantic overlap has been described as, at best confusing, as worse outright dangerous because newcomers start to ascribe some kind of magic properties.- The “Monad of no Return” proposal by Ben Gamari explains in length why
returnis mostly an artifact of the past:
Consequently, the Monad class is left with a now redundant return method as a historic artifact, as there's no compelling reason to have pure and return implemented differently. More to the point, this redundancy violates the "making illegal states unrepresentable" idiom: Due to the default implementation of return this redundancy leads to error-prone situations which aren't caught by the compiler; for instance, when return is removed while the Applicative instance is left with a pure = return definition, this leads to a cyclic definition which can be quite tedious to debug as it only manifests at runtime by a hanging process. Traditionally, return is often used where pure would suffice today, forcing a Monad constraint even if a weaker Applicative would have sufficed. As a result, language extensions like ApplicativeDo[3] have to rewrite return to weaken its Monad m => constraint to Applicative m => in order to benefit existing code at the cost of introducing magic behavior at the type level.