The HLS had problem that it was detecting the cabal.project in root of our
monorepo, but also was founding the Setup.hs that promised that it is a simple
project structure. And was trying to run the Core with `runhaskell`.
So HLS was throwing several errors. The explicit definition of cradles allowed
HLS to understand that it is a monorepo. And the removement of Setup.hs is
because it is not recommended anymore, and upstream work plans to deprecate it
completely in favour of arriving proper solution.
Allow not only lists.
This for example should allow NonEmpty lists at least.
Also do not think I do this things on a whim.
I did some research on: is there a reason to use map over fmap, and are the
performance reasons?
In short - there is 0 infornamation on why some people use `map` over `fmap`, there
are no reports of performance reasons.
Well, I know that there is a possibility of a minor type class interface
compilation & runtime use cost. But I think GHC is good enough to infer zero
cost for the concrete list type for which `map` gets used.
And overall we not did thorough profiling/perfommans walkthrough so far. I am
sure that use of standard fmap for code flexibility is not a bottleneck in the
design, I've seen some performance problems design has.
And we not even did the profiling to do inlining and specialize work yet. It is
more effective to keep using `fmap`, and supply specialization, which allows to
keep the code polymorhic, portable to write for and effective in performance.
*afaik* (++) does not even work with OverloadedStrings with Text or ByteString.
Lets allow ourselves to switch from [] & Strings in Haskell in any part of the code.
`brittany` was used.
Then all changes passed through manual supervision.
Then handcrafted code cleanup was done.
All changes are pure lambda code refactoring,
there should be no changes to the functionality.
cryptohash-sha512 unmaintained, PR adds support of base 4.14 (GHC 8.10).
The fork got version restriction and several tests removed.
A hnix-store-core/cabal.project
