On Sat, Sep 27, 2014 at 7:40 PM, Brandon Allbery wrote:

There is a difference between the libraries needed to provide a core usable Haskell installation, and the libraries required for a particular Haskell implementation (in this case ghc) to provide basic functionality. For example, integer-gmp is an artifact of how GHC implements bigints, and haskeline and terminfo are required for ghci's line editing. We generally distinguish between "core libraries" and "GHC bootstrap libraries" ("bootlibs").

Thanks Brandon, that cleared up part of my initial confusion. I added the following section to the haskellwiki: http://www.haskell.org/haskellwiki/Applications_and_libraries#GHC_bootstrap_...

On Sun, Sep 28, 2014 at 11:35 PM, Gershom B wrote:

Better perhaps to do something like the following:

"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. 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.”

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

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. The implementations themselves should (and indeed must) maintain their implementation libraries lists; 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. -- brandon s allbery kf8nh sine nomine associates allbery.b@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net

On Sun, Sep 28, 2014 at 11:43 PM, Brandon Allbery wrote:

On Sun, Sep 28, 2014 at 11:35 PM, Gershom B wrote:

...

Better perhaps to do something like the following:

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

Sadly this isn't true. 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.

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

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

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.

The implementations themselves should (and indeed must) maintain their implementation libraries lists;

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.

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

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

-- You received this message because you are subscribed to the Google Groups "haskell-core-libraries" group. To unsubscribe from this group and stop receiving emails from it, send an email to haskell-core-libraries+unsubscribe@googlegroups.com. For more options, visit https://groups.google.com/d/optout.

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 wrote:

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

Hi Edward, Thank you for your explanation. I would still like to make sure [1] is up-to-date, since those are the packages for which third party contributions need to go through the library submissions process. Do you have a complete list of the packages maintained by the Core Libraries Committee? Thanks, Thomas [1] http://www.haskell.org/haskellwiki/Library_submissions#The_Core_Libraries

The list that we maintain is the list you referenced. =)

If there is a package we're supposed to maintain as part of the platform, we add it to that list and put our name next to it.

Ok, final question: What about filepath and hpc? Their .cabal files list libraries@haskell.org as maintainer, which usually means the Core Libraries Committee. Should filepath be added to that list, and the maintainer for both filepath and hpc be set to the Core Libraries Committee? If not, who maintains filepath? Thanks, Thomas

There is some allowance for historical accident.. er precedent. ;) -Edward On Sun, Sep 28, 2014 at 7:53 AM, harry wrote:

Edward Kmett wrote

...

We have the Haskell Platform, which is basically a bunch of our "best of breed" packages we believe everyone should have installed by default

How does html fit that description?

-- View this message in context: http://haskell.1045720.n5.nabble.com/List-of-core-libraries-tp5757100p575714... Sent from the Haskell - Libraries mailing list archive at Nabble.com. _______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries