<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Sep 27, 2016 at 5:25 PM, Olaf Klinke <span dir="ltr"><<a href="mailto:olf@aatal-apotheke.de" target="_blank">olf@aatal-apotheke.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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.</blockquote></div><br>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.<br clear="all"><div><br></div><div>The complications are:</div><div><br></div><div> - libraries change quickly and dependents tend to start requiring the new versions just as quickly, rendering the batteries included obsolete almost immediately;</div><div> - 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.</div><div><br></div><div>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.</div><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div>brandon s allbery kf8nh                               sine nomine associates</div><div><a href="mailto:allbery.b@gmail.com" target="_blank">allbery.b@gmail.com</a>                                  <a href="mailto:ballbery@sinenomine.net" target="_blank">ballbery@sinenomine.net</a></div><div>unix, openafs, kerberos, infrastructure, xmonad        <a href="http://sinenomine.net" target="_blank">http://sinenomine.net</a></div></div></div>
</div></div>