Haskell 2010: libraries
marlowsd at gmail.com
Thu Jul 9 07:46:31 EDT 2009
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 220.127.116.11 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
Any other thoughts?
More information about the Haskell-prime