
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
On Mon, Sep 29, 2014 at 12:32 AM, Edward Kmett
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