[Haskell-beginners] coming to grips with hackage

[Brandon Allbery]

On Thu, Feb 6, 2014 at 9:36 PM, <tam at hiddenrock.com> wrote:

> ... Haskell seems worse to me in that if package foo is updated, every
> other
> package depending on foo (recursely) must then be rebuilt, even if they
> didn't
> change and even if the interface presented by foo didn't change.
>

This is something of a problem, yes... but it's not really "Haskell"'s
fault. It's a specific design decision in GHC, in the name of performance:
aggressive cross-module inlining means that specific compilation details of
dependencies leak into the ABI of their dependents, necessitating exact ABI
matches instead of simply consonant versions as in (normal) C. (For
comparison, note that KDE has often had exactly the same problem in C++,
through using cpp macros in place of inline functions for performance on
"hot paths"; the exact macro and *every* (external or internal)
function/method/variable it touches becomes part of the "public" ABI that
must be maintained for compatibility.)

Other Haskell compilers such do things differently. ajhc is a whole-program
compiler, so in fact you *always* compile your dependencies again from
source. uhc I don't think does the same amount of cross-module inlining, at
a performance cost but maintainability gain. (And "Cabal hell" is shooting
the messenger; it's just reporting the mess ghc has made / will make.)

I do find myself wondering if anyone has checked to see how important the
inlining is these days; perhaps ghc's general performance (and a hat tip to
Moore's law) has made it possible to consider compiling more stable
libraries.

-- 
brandon s allbery kf8nh                               sine nomine associates
allbery.b at gmail.com                                  ballbery at sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/beginners/attachments/20140206/11dea712/attachment.html>