Haskell 2010: libraries

[Simon Marlow]

On 11/07/2009 11:54, Manuel M T Chakravarty wrote:
> Ross Paterson:
>> On Wed, Jul 08, 2009 at 03:09:29PM +0100, Simon Marlow wrote:
>>> 1. Just drop the whole libraries section from the report. The
>>> Report will still define the Prelude, however.
>>>
>>> There will be some loose ends where the rest of the report
>>> refers to entities from these libraries, e.g. the Prelude
>>> refers to Rational from the Ratio library. We just have to
>>> fix up these references, moving the appropriate definitions
>>> into the Report as necessary.
>>
>> Some of the loose ends:
>>
>> The defaulting rules (section 4.3.4) apply to any class "defined in the
>> Prelude or a standard library". The non-Prelude classes involved are
>> Ix and Random.
>>
>> The FFI spec refers to types Int8, Int16, Int32, Int64, Word8, Word16,
>> Word32, Word64, Ptr a, FunPtr a and StablePtr a. Perhaps they should move
>> to the Prelude when the non-library part of the FFI spec is incorporated
>> into the Report?
>
> If we have these types in the Prelude, the associated functions should
> be in the Prelude, too, and I'd be reluctant to include operations that
> are not memory-safe in the Prelude. So, I think, we need at least a
> standard library for the FFI. (In the FFI spec, we after all went to a
> lot of trouble to realise as much as possible of the needed
> functionality as libraries, to change the core language as little as
> possible.)

The functions don't necessarily have to be in the Prelude too - the 
point of putting the types there is so that we can specify what a valid 
foreign import/export declaration is.

> I understand the desire to cut down on the number of library functions
> defined in the report, but ultimately, the language needs to provide a
> basic set of functionality that is the basis for implementing all the
> other libraries. Otherwise, the usefulness of the standard gets undermined.

The usefulness of the standard is already undermined by specifying a set 
of libraries that we don't recommend people use, and that differ in 
confusing ways from the libraries that we do recommend people use (e.g. 
they have different names, such as CForeign vs. Foreign.C).

I'm all for having standard libraries, but we have to think about what 
we can practically accomplish for Haskell 2010.

> Apart from the Prelude, I think we should ask the following question to
> decide whether we can omit some library functionality from the language
> definition:
>
> If we omit the functionality under consideration,
> can we implement it in a portable manner with what remains in the
> definition?
>
> If that is not the case, we ought to include it.

I don't like to think of this in terms of "omitting functionality from 
the language definition".  It's more a case of deferring the 
standardisation of libraries in the Report, until such time as we can 
produce a polished library standard.  The functionality is still there, 
in the implementations, well documented, and in the FFI spec.  It is 
also explicitly versioned in the Haskell Platform, so language 
implementers can all agree on what to provide.

To use the above test would mean we could avoid specifying some 
libraries but not others, based on some criteria that is not important 
to users.  I don't think this is the right way to approach the problem. 
  Some libraries inevitably have non-portable implementations: e.g. 
Data.Typeable, Control.Exception, Data.IORef.  We would be able to leave 
out Data.List, but not Foreign.StablePtr.  Which is more useful?

Another option (option (3) in my original mail) is to rename all the FFI 
libraries to use the hierarchical names and include them in the Report. 
  But what other libraries should we include?  I favour this approach 
slightly less than just leaving out all the libraries, mainly because 
the result would be an fairly arbitrary collection of library modules, 
which is of limited use to both users and language implementers.  It may 
serve as a start for a larger collection of standard libraries; however, 
it would also be quite a lot of work to get this done for Haskell 2010.

> PS: As a historical anecdote, it was a major shortcoming of Modula-2
> over C that Modula-2 didn't define it's basic libraries properly with
> the language (whereas C did).

I completely agree there should be standard libraries.  But I don't 
think that should prevent us from producing a language revision in the 
short term.

Cheers,
	Simon