I've updated the verbiage on the Library_Submissions process to capture a bit more about the effective role of the core libraries. It was rather messy before.

I do agree we do probably want to do more to break out what portions of the core-libraries are intended for portable implementation and which ones are just things we simply have to maintain for glue, but for that we'd probably need more feedback from other compiler implementors to get a sense of what it is they have been able / willing to implement.

-Edward

On Mon, Sep 29, 2014 at 12:44 AM, Brandon Allbery <allbery.b@gmail.com> wrote:
On Mon, Sep 29, 2014 at 12:32 AM, Edward Kmett <ekmett@gmail.com> wrote:
 
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.
 
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.

Yes, de facto this only means GHC at present. But it also captures, or intends to capture, your statement:

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).

--
brandon s allbery kf8nh                               sine nomine associates
allbery.b@gmail.com                                  ballbery@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net