<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sun, Sep 28, 2014 at 11:43 PM, Brandon Allbery <span dir="ltr"><<a href="mailto:allbery.b@gmail.com" target="_blank">allbery.b@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><span class=""><div class="gmail_quote">On Sun, Sep 28, 2014 at 11:35 PM, Gershom B <span dir="ltr"><<a href="mailto:gershomb@gmail.com" target="_blank">gershomb@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="overflow:hidden">Better perhaps to do something like the following:<br>
<br>
"The core libraries are a subset of the packages in the Haskell Platform. Many core libraries define basic APIs that are expected to be available in any Haskell implementation. </div></blockquote></div></span></div></div></blockquote><div><br></div><div>Sadly this isn't true. </div><div><br></div><div>The core libraries are simply basic APIs that are parts of the Haskell Platform that aren't maintained by another individual. The Haskell Platform consists more or less of stuff we need to ship to be useful and/or is too hard to expect an end user to figure out how to build but which deserves broad distribution.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><span class=""><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="overflow:hidden">A second set of core libraries are coupled tightly to the Glasgow Haskell Compiler but nonetheless managed through the core libraries process, as they are considered core functionality in the GHC Haskell ecosystem.”<br>
<br>
Additionally, the libraries committee may want to more explicitly seperate the two lists? If we do ever have a new libraries section of a Haskell report, I imagine, e.g. it may well mention directory and process, but not ‘ghc-prim’.<br></div></blockquote></div><br></span>I would argue that implementation specific libraries do not belong in the core libraries list. Instead, perhaps the libraries committee should state two functions: maintaining the core libraries list, and acting as the community interface/liaison for libraries specific to implementations.</div></div></blockquote><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra">The implementations themselves should (and indeed must) maintain their implementation libraries lists;</div></div></blockquote><div><br></div>The main thing the core libraries committee does right now is deal with that uncomfortable buffer zone between what GHC HQ wants to deal with (making GHC fast and nice to use) and what the rest of the ecosystem wants to maintain (many of the individual maintainer packages in the platform). There were a whole lot of packages left to this grey area, needed by the rest of the platform, but where it was basically assumed that GHC HQ was maintaining them but really nobody felt ownership.<div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra">but to the extent that the community affects and is affected by these lists, the libraries committee is empowered to act on behalf of the community.</div></div></blockquote><div> <br></div><div><div>If there are other teams working on compilers that want to engage with the core libraries committee to get better interoperability, we'd be happy to engage, but thus far, GHC is the only party at the table actively talking to us.</div></div><div><br></div><div>-Edward</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><span class=""><div></div>-- <br><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>
</span></div></div>
<p></p>
-- <br><div class=""><div class="h5">
You received this message because you are subscribed to the Google Groups "haskell-core-libraries" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an email to <a href="mailto:haskell-core-libraries+unsubscribe@googlegroups.com" target="_blank">haskell-core-libraries+unsubscribe@googlegroups.com</a>.<br>
For more options, visit <a href="https://groups.google.com/d/optout" target="_blank">https://groups.google.com/d/optout</a>.<br>
</div></div></blockquote></div><br></div></div>