Haskell 2010: libraries

Malcolm Wallace malcolm.wallace at cs.york.ac.uk
Tue Jul 14 04:27:22 EDT 2009

A natural "language" consists of a vocabulary of words, as well as a  
grammar for stringing them together.  If we omit the common basic  
libraries from the language definition, then are we implicitly  
reducing the common vocabulary, and encouraging dialects to appear?   
If I see the function "scanr" in a module, should I expect that it has  
the semantics of Data.List.scanr?  Or is it OK for someone to define  
their own Data.List with different semantics?

> Keep the commonly used and uncontroversial (mostly pure) modules and
> rename them to use the new hierarchical module names.

I would largely concur with this policy, with the caveat that  
additions to the API might appear in future.  Also, the hierarchical  
versions of the FFI libraries are essential.

>     3. Numeric		keep as Numeric (?)

I think we could take the opportunity to rename it to Text.Numeric.   
Why Text?  Because it only defines ReadS and ShowS things (with the  
exception of fromRat, and floatToDigits, sigh, which should be moved  

> It'd be nice to have a clear dividing line of keeping the pure stuff  
> and
> dropping the bits for interacting with the system ... The bits for  
> interacting with the system are of course exactly the bits that are  
> most prone to change and are most in need of improvement.

In some ways, it is _more_ important to standardise the difficult  
bits, i.e. interacting with the system, because otherwise it is  
desparately difficult to write portable programs.  But I agree that  
the choices made in H'98 and earlier to abstract over the underlying  
OS were probably rather poor and inflexible, and it is probably  
unrealistic to be able to propose a new stable API for a couple of  
years yet.  I do think we should set it as a goal for the future  


More information about the Haskell-prime mailing list