Haskell 2010: libraries

[Simon Marlow]

On 08/07/2009 19:41, Heinrich Apfelmus wrote:
> Bulat Ziganshin wrote:
>> Simon Marlow wrote:
>>
>>>    3. Update the libraries to match what we have at the moment.
>>>       e.g. rename List to Data.List, and add the handful of
>>>       functions that have since been added to Data.List.  One
>>>       problem with this is that these modules are then tied to
>>>       the language definition, and can't be changed through
>>>       the usual library proposal process.
>> not necessarily. we already apply versioning to these libs, it may be
>> made official in Report too. i.e. Report defines libraries standard
>> for year 2010 (like it defines language standard for only one year),
>> while we continue to improve libraries that will eventually become
>> version standard for year 2011 (or higher)
>
> If I understand that correctly, this would mean to simply include the
> particular version of a library that happens to be the current one at
> the report deadline. In other words, the report specifies that say
> version 4.1.0.0 of the base library is the standard one for 2010.
>
> Since old library versions are archived on hackage, this looks like a
> cheap and easy solution to me. It's more an embellishment of alternative
> 1. than a genuine 3.

So, just to be clear, you're suggesting that we

   - remove the whole of the Library Report,

   - declare a list of packages and versions that we consider
     to be the standard libraries for Haskell 2010.

This would be a bold step, in that we would be effectively standardising 
a lot more libraries than the current language standard.  The base 
package is a fairly random bag of library modules, for instance.  It 
contains a lot of modules that are only implemented by GHC.  It contains 
backwards compatibility stuff (Control.OldException), and stuff that 
doesn't really belong (Data.HashTable).  Perhaps we could explicitly 
list the modules that the standard requires.

On the other hand, this would be a useful step, in that it gives users a 
wide base of libraries to rely on.  And it's cheap to implement in the 
report.

Any other thoughts?

Cheers,
	Simon