[Haskell-cafe] Batteries included (Was: GHC is a monopoly compiler)

[Brandon Allbery]

On Tue, Sep 27, 2016 at 5:25 PM, Olaf Klinke <olf at aatal-apotheke.de> wrote:

> Can someone please define what exactly a "batteries included" standard
> library is? IMHO that Python-Haskell comparison is unfair. Although both
> claim to be general-purpose languages, the focus in Haskell certainly has
> been on language research for most of its life.


It means that useful libraries that most projects use come with it: in a
Haskell context, that would be things like text, unordered-containers, and
split. It's also a bikeshed, though: for example, H-P insisted on adding
OpenGL because it was felt to be important to include some kind of GUI, but
the Haskell GUI story is so fragmented and messed up that it doesn't seem
really worth it --- and OpenGL basically got the nod solely on being
readily portable to Linux/Windows/macOS without having to hunt down extra
native libraries, not because it was actually being used by itself. This
led to endless discussion on the libraries list.

The complications are:

 - libraries change quickly and dependents tend to start requiring the new
versions just as quickly, rendering the batteries included obsolete almost
immediately;
 - in the opposite direction, some libraries that come with the compiler
because it uses them (notably, containers) are effectively frozen because
ghc-api or TH or etc. will break.

Additionally, and causing the above complications to often be fatal, ghc's
own library story --- specifically cross-module inlining, which is
essential for performance --- results in things which would be sensibly
hidden internal details and therefore ABI-breakage-safe often leaking out
into the .hi file for cross-module inlining, making the internals part of
the public ABI. This is really the primary cause of ghc's library
nightmares, and why other languages usually don't have these kinds of
problems (but older C and C++ code sometimes did, by exposing internals in
header file macros, again for speed; original mh (not nmh) and KDE 1/2 (but
not 3.x or later) are examples). But you can't really generate code from
Haskell with any reasonable performance unless you resort to either
cross-module inlining (ghc) or whole-program compilation (jhc). :( Tools
like cabal-install and stack have to do all sorts of otherwise "nonsensical
extra work" to try to avoid running headlong into this.

-- 
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://mail.haskell.org/pipermail/haskell-cafe/attachments/20160927/b53ec5cc/attachment.html>