From 6d41ea372abe86a7df108be0604b405e1db7762d Mon Sep 17 00:00:00 2001 From: Ian Lynagh Date: Tue, 6 Mar 2007 15:26:54 +0000 Subject: [PATCH] Remove outdated libraries/doc/libraries.xml and libraries/doc/libtable.xml --- libraries/doc/libraries.xml | 1540 ------------------------------------------- libraries/doc/libtable.xml | 815 ----------------------- 2 files changed, 2355 deletions(-) delete mode 100644 libraries/doc/libraries.xml delete mode 100644 libraries/doc/libtable.xml diff --git a/libraries/doc/libraries.xml b/libraries/doc/libraries.xml deleted file mode 100644 index 03d3ecf..0000000 --- a/libraries/doc/libraries.xml +++ /dev/null @@ -1,1540 +0,0 @@ - - -]> - -
- - Hierarchical Haskell Libraries - The Haskell Libraries Mailing List -
libraries@haskell.org
- - - - Introduction - - The Hierarchical - Module Namespace Extension is a modest extension to Haskell 98 - which replaces the existing flat module namespace with a - hierarchy. - - This document constitutes a proposal for how the new - hierarchical namespace should be used. It is - not an addendum to the Haskell 98 report: the - contents of this document are still under discussion on the - libraries@haskell.org - mailing list, and are subject to change. - - The most up to date version of this document can be found in - the GHC - darcs repository in the directory - libraries/doc. - - The proposal has several parts: - - - - An allocation of the new module namespace to existing - and non-existent libraries, people, organisations, and local - use. - - - A policy and procedure for allocating new parts of the - namespace. - - - A set of libraries which are under the control of the - community and have reference implementations. These libraries - will vary from almost completely stable (eg. the - Prelude) to experimental libraries with - fast-changing APIs. Throughout this document, these libraries - shall be referred to as the Reference - Libraries. The reference libraries serve to both - define the library APIs, and provide implementations; in most - cases this will be the primary implementation of that - library. - - - - In addition, this document also describes: - - - - Guidelines and conventions for organising the - hierarchy. - - - Our policy with respect to the design and evolution of - library APIs, versioning of library APIs, and maintenance of - the reference implementation. - - - A set of conventions for coding style and portability - within the libraries. - - - - - - How to contribute - - This project is driven by the Haskell community, so - contributions of all kinds are welcome. The first step is to join - the Haskell - libraries mailing list, and maybe browse the list - archives. Some of the ways you can contribute are: - - - - By donating code: for libraries which don't yet have a - reference implementation, code is always welcome. Code that - conforms to the design guidelines (which aren't very strict, - see ) and comes with documentation - () and a test suite () is better, but these aren't essential. As - a library progresses through the stability scale () these things become more important, but - for an experimental library we're not going to worry too much - about this stuff. - - See section for details on - contributing new library code. - - - By porting code for an existing library to a new - compiler or architecture. A library is classed as portable if - it should be available regardless of which compiler/platform - combination you're using; however, many libraries are - non-portable for one reason or another (see ), and broadening the scope of these - libraries is always welcome. - - - Become a library maintainer: if you have a particular - interest in and/or knowledge about a certain library, and have - the time to spare, and the library in question doesn't already - have a maintainer, then you may be a suitable maintainer for - the library. The responsibilities of library maintainers are - given in . - - - Participating in the design process for new libraries, - and suggesting improvements to existing libraries. Everyone - on the Haskell - libraries mailing list is invited to - participate in the design process, so get involved! - - - - - - - - - - The hierarchy - - We first classify each node in the hierarchy according to - one of the following terms: - - - - Allocated - - Nodes in the hierarchy can be allocated to a library. - The currently allocated nodes are specified in . - - - - - User - - The User hierarchy is reserved for - users: a user may always use the portion of the hierarchy - which is formed from his/her email address as follows: - replace any .s in the - username (before the @) with - _, replace the - @ by a - ., reverse the order of - the components, capitalise the first letter of each - component, and prepend - User.. For example, - simonmar@microsoft.com becomes - User.Com.Microsoft.Simonmar. - - - - - Organisation - - The Org hierarchy is reserved for - organisations. Any organisation with a DNS domain name owns - a unique space in the hierarchy formed by reversing the - components of the domain, capitalising the first character - of each component, and prepending Org.. - ToDo: the Org name isn't great, especially when - the domain name also ends with Org (eg. Org.Org.Haskell?). - Contrib has also been suggested. - - - - - Local - - The Local hierarchy is reserved for - libraries which are local to the current site. Libraries - which are to be distributed outside the current site should - not be placed in the Local - hierarchy. - - - - - Unallocated - - Any node which doesn't belong to any of the above - categories is currently unallocated, and is available for - use by Haskell programs. - - - - - A node in the hierarchy may be both a specific library and a - parent node for a number of child nodes. For example, - Foreign is a library, and so is - Foreign.Ptr. - - - Hierarchy design guidelines - - Apart from the User, - Local and Org top-level - categories, the rest of the hierarchy is organised with a single - principle in mind: - -
- Modules are grouped by - functionality, since this is the single - property that is most helpful for a user of the library - we - want users to be able to find out where to obtain - functionality easily, and to easily find all the modules that - provide relevant functionality. - - So, if two modules provide similar functionality, or - alternative interfaces to the same functionality, then they - should be children of the same node in the hierarchy. Modules - should not be grouped by standards compliance, portability, - stability, or any other property. -
- - It should be noted that this is a guideline rather than a - rule: sometimes it just isn't the right thing. For example, the - DotNet top-level name contains a mirror of - the Microsoft .NET base class library; if we had gone purely by - functionality then these libraries would have to be scattered - around the hierarchy, resulting in a situation where it would - probably be harder for a programmer to find - the functionality he or she is interested in. - - There are some other considerations when choosing where to - place libraries. Where possible, choose a layout that finds a - good compromise between depth of nesting and logical grouping of - functionality; for example, although the Text - hierarchy could logically be placed as a child of - FileFormat, we choose not to because - Text is ubiquitous and we don't want to have - to type the extra component all the time. - - Also consider consistency: if a particular sub-hierarchy - provides similar functionality to another sub-hierarchy in the - tree, then preferably the structure of the two subtrees should - also be similar. For example: under - Language.Haskell we have children - Syntax, Lexer, - Parser etc., so under - Language.C we should have a similar - structure. - - - - Module naming conventions - - - - A module defining a data type or type class - X has itself the name - X, e.g. - StablePtr. - - - - A module which re-exports the modules in a subtree of - the hierarchy has the same name as the root of that subtree, - eg. Foreign re-exports - Foreign.Ptr, - Foreign.Marshal.Utils etc. - - - - If a subtree of the hierarchy contains several modules - which provide similar functionality (eg. there are several - pretty-printing libraries under - Text.PrettyPrinter), then the module at - the root of the subtree generally re-exports just - one of the modules in the subtree - (possibly the most popular or commonly-used - alternative). - - - - In Haskell you sometimes publish - two interfaces to your libraries; one - for users, and one for library writers or advanced users who - might want to extend things. Typically the advanced users - need to be able to see past certain abstractions. - - The current proposal is for a module named - M, the advanced version - would be named M.Internals. eg. - - -import Text.HTML -- The library -import Text.HTML.Internals -- The non-abstract library - - - - - Acronyms are fully capitalised in a module name. - eg. HTML, URI, - CGI, etc. Exceptions may be made for - acronyms which have an existing well-established alternative - capitalisation, or acronyms which are also valid words, and - are more often used as such. - - - - A module name should be made plural only if the module - actually defines multiple entities of a particular kind: - eg. Foreign.C.Types. Most module names - which define a type or class will follow the name of the - type or class, so whether to pluralize is not an - issue. - - - - - - The top-level names - - The currently allocated nodes in the hierarchy are listed - in the next section (). In - addition, for each top-level name we describe its intended - purpose below: - - - - Control - - Libraries which provide functions, types or classes - whose purpose is primarily to express control - structure. - - - - - Data - - Libraries which provide data types, operations over - data types, or type classes, except for libraries for - which one of the other more specific categories is - appropriate. - - - - - Database - - Libraries for providing access to or operations for - building databases. - - - - - Debug - - Support for debugging Haskell programs. - - - - - DotNet - - Mirrors the Microsoft .NET base class hierarchy, for - systems providing access to the .NET libraries. - - - - - Edison - - The Edison data structure library. - - - - - Codec - - Support for (en)coding and decoding data in various - formats. Codec encompasses compression - (both lossy and non-lossy) codings, transport - codings, and encryption. - - - - - Foreign - - Interaction with code written in a foreign - programming language. - - - - - Graphics - - Libraries for producing graphics or providing - graphical user interfaces. - - - - - Language - - Libraries for operating on or generating source code - in various programming languages, including parsers, - pretty printers, abstract syntax definitions etc. - - - - - Local - - Available for site-local use. - - - - - Numeric - - Functions and classes which provide operations over - numeric data. - - - - - Network - - Libraries for communicating over a network, - including implementations of network protocols. - - - - - Org - - Allocated to organisations on a domain-name - basis (see ). - - - - - Prelude - - Haskell98 Prelude (mostly just re-exports other - parts of the tree). - - - - - System - - Libraries for communication with the system on which - the Haskell program is running (including the runtime - system). - - - - - Text - - Libraries for parsing and generating data in a - textual format (including structured textual formats such - as XML, HTML, but not including programming language - source, which lives in Language). - - - - - GHC - - Libraries specific to the GHC/GHCi system. - - - - - Nhc - - Libraries specific to the Nhc compiler. - - - - - Hugs - - Libraries specific to the Hugs system. - - - - - User - - Allocated to individual users, using email - addresses (see ). - - - - - - - Allocated libraries - - - - - - Library - Maintainer - URL - - - - &libtable; - - - - - - - - Reference libraries - - There are reference implementations for many of the - libraries allocated in the hierarchy (see ). These reference libraries serve to define - the API for each library, and also in most cases provide the - primary implementation of that library. We don't discount the - possibility that multiple implementations of libraries may exist, - but there is only ever one reference implementation. - - Many of the reference libraries live in the CVS repository - on cvs.haskell.org under the directory fptools/libraries, - but others are maintained and distributed separately by members of - the Haskell community. lists the - maintainer for each reference library, and a location from which - the code can be obtained. - - - Installing libraries - - Compilers are normally distributed with a number of - libraries, which may or may not be built from the reference - implementations. - - Currently, the procedure for installing a library which is - not distributed with your compiler is currently dependent on a - number of things: platform, compiler, and how much support is - provided by the library maintainer. We aim to standardise this - procedure to a certain extent by providing a library - infrastructure which automates the building, installation and - packaging of libraries for all architectures and compilers. The - means by which we might achieve this are being actively - discussed: see the libraries - mailing list archives. - - - - Contributing new reference libraries - - The process for contributing a new library is as - follows: - - - - Allocate module names. - - If you want a library in the User - or Org part of the hierarchy, then - nothing needs to be done: just go ahead and distribute - your library. - - If, however, you are providing a library for any - other part of the hierarchy, then the module names in the - should be allocated. - lists the parts of the hierarchy that are currently - allocated. - - There are several reasons for allocating module - names centrally in this way: - - - - Haskell users have the guarantee that libraries - never conflict with each other by using the same - module name. - - - There is always one place to obtain a given - library, each library has a single reference - implementation, and there is a single point of contact - for the implementor(s). - - - - Remember that this only applies to libraries: code - in a program can use whatever module - names it chooses (but it's probably a good idea to avoid - conflicting with any libraries that might be installed: - avoiding the allocated module names is a good way to - ensure that). - - To allocate module names for a new library, send - mail to libraries@haskell.org describing - your library and which module names you are proposing to - allocate. Provided there is no conflict, then the names - will normally be allocated and added to the list above. A - conflict might arise if for example someone else wants to - provide a library with the same name; conflicts will be - resolved by consensus on a case-by-case basis. - - - - - Distribute the library. - - The mechanism by which libraries should be - distributed is currently being discussed; we hope in the - future to make the process much easier for library - writers. Currently you have to do all the work yourself: - write a build system (or steal one), installation scripts - and support for packaging on each platform that you wish - to support. - - - - - - - Licensing - - Following some discussion on the mailing list related to - how we should license the libraries, the viewpoint that was - least offensive to all involved seems to be the - following: - - We wish to accommodate source code from different - contributors, and with different licenses. However, a library - of modules where each module is released under a different - license, and where the dependencies between modules aren't - clear, isn't workable (it's too hard for a user of the library - to tell whether they're violating the terms of the each license - or not). - - So the solution is as follows: code under different - licenses will be clearly separate in the repository (i.e. in - separate subdirectories), and compilers are expected to present - packages of modules where all modules in a package fall under - the same license, and where the dependencies between packages - are clear. - - It was decided that certain essential functionality should - be available under a BSD style license. Hence, the BSD part of - the repository will contain implementations of at least the - following modules: Prelude, - Foreign, ToDo: what - else?. - - There is one further requirement: reference libraries must - be available under a license approved by the Open Source - Initiative. See The - Open Source Initiative for a list of approved - licensees. - - - - Versioning - ToDo - - - - Library stability - - The stability of a library relates primarily to its API. - Stability provides an indication of how often the API is likely - to change (or whether it may even go away entirely). - - The stability scale is also a measure of how strictly the - conventions in this document are applied to the library: an - experimental library isn't subject to any restrictions regarding - coding style and documentation, but a stable library is expected - to adhere to the guidelines, and come with full documentation - and tests. - - To help with the stability issue, library maintainers are - allowed to mark functions, types or classes as - deprecatedCompilers may - have extra support for warning about the use of a deprecated - feature, for example GHC's DEPRECATED - pragma. , which means simply that the feature - will be removed at a later date. Just how long it will stick - around for depends on the stability category of the library (see - below). A feature is marked as deprecated in the documentation - for the library, and optionally in an implementation-dependent - way which enables the system to warn about the use of deprecated - features. - - The current stability categories are: - - - - experimental - - An experimental library is unrestricted in terms of - API changes: the API may change between minor revisions - and there is no requirement to retain old interfaces for - compatibility. Documentation and tests aren't required - for an experimental library. - - - - provisional - - A provisional library is moving towards stability, - and the rate of change of the API is slower. API changes - between minor revisions must be accompanied by deprecated - versions of the old features where possible. API changes - between major versions are unrestricted. The library - should come with at least rudimentary - documentation. - - - - stable - - A stable library has an essentially fixed API. - Additions to the API may be made for a minor release, - deprecated features must be retained for at least one - major revision, and small changes only may be made to the - existing API semantics for a major revision. A stable - library is expected to include full documentation and - tests. - - - - - - - - Portability considerations - - The portability status of a library affects which - platforms and compilers the library will be available on. The - precise meaning of the terms portable and non-portable for our - purposes are given below: - - - - Portable - - A library which is available on all platforms and - with all Haskell implementations is portable. - - A portable library may make use of non-portable - features or import non-portable libraries in its - implementation, as long as it does so conditionally and - provides the same interface on all platforms and with all - Haskell implementations. - - - - Non-portable - - A non-portable library may be non-portable for one - or more of the following reasons: - - - Requires extensions - - A library which uses non-approved language - extensions in its implementation, and has no - portable fallback implementation. - - - - Requires nonportable libraries - - A library which depends (directly or indirectly) - on other non-portable libraries. - - - - OS-specific - Platform-specific - - A library which depends on features or APIs - particular to a certain OS or platform is - non-portable for that reason. - - - - - - - - - Approved extensions - - Very few of the reference libraries can be implemented - using pure Haskell 98. For this reason, we decided to raise - the baseline for portable libraries to include a few common - extensions; the following language extensions can be - assumed to be present when writing - libraries: - - - - The Foreign - Function Interface. - - - Mutable variables - (Data.IORef). - - - Unsafe IO monad operations - (System.IO.Unsafe). - - - Packed strings - (Data.PackedString). - - - Bit operations (Data.Bits). - - - - Extensions which we'd like to be standard, but aren't - currently implemented by one or more of the target - compilers: - - - - Exceptions (synchronous only), defined by the - Control.Exception interface. - - - The ST monad, defined by - Control.Monad.ST, and the associated - Data.Array.ST and - Data.STRef libraries. ST requires a - small typechecker extension for the - runST function. - - - Concurrent Haskell (pre-emptive multitasking - optional). GHC and Hugs implement this, but Nhc currently - does not. - - - - The following extensions are not likely to become part - of the baseline, but are nevertheless used by one or more - libraries in the reference set (which are thus designated - non-portable): - - - - Multi-parameter type classes. - - - Local universal and existential quantification. - - - Concurrent Haskell with pre-emptive multitasking. - - - Asynchronous exceptions. - - - Stable Names. - - - Weak Pointers. - - - - Other extensions are supported by a single compiler - only, and can be accessed by libraries under the top level - hierarchy for that compiler, - eg. GHC.UnboxedTypes. - - - - - Library maintainers - - This is a collaborative project, so we like to devolve - control of the design and implementation of libraries to those - with an interest or appropriate expertise (or maybe just the - time!). A maintainer isn't necessarily a single person - for - example, the listed maintainer for most of the reference - libraries is libraries@haskell.org, indicating - that the library is under the control of the community as a - whole. The maintainer for the Foreign - hierarchy is ffi@haskell.org, the mailing list - for discussion of the Haskell FFI standard. - - The responsibilities of a library maintainer include: - - - - Most importantly: act as a single point of contact for - issues relating to the library API and its - implementation. - - - Manage any discussion related to the library (which - can take place on libraries@haskell.org if - necessary), and summarise the results. Make final - decisions, and implement them. - - - Maintain the implementation, including: fixing bugs, - updating to keep up with changes in other libraries, porting - to new compilers/platforms, and integrating code from other - contributors. The maintainer is expected to be the only - person/group to make functional changes to the source code - (non-functional or trivial changes don't count). - - - Maintain/write the documentation and tests. - - - If you can't maintain the library any more for - whatever reason, tell libraries@haskell.org - and we'll revert the maintainer status of the library to the - default. - - - - - - Documentation - - We are using Haddock to - document the libraries. Haddock generates nice hyperlinked HTML - output directly from the Haskell source, and understands - comments written in a particular style as documentation - annotations, which are merged with the generated - documentation. - - Before submitting code to the libraries project, please - ensure that it passes through Haddock without complaint. Even - if it contains no actual documentation annotations, we'll get - useful documentation out of the source alone (type signatures, - data types, etc.). - - - - Coding style - - - Standard module header - - Using a standard module header makes it easy to - automatically extract meta-information from library source - code, such as the stability/portability of individual modules. - We recommend using the following module header for reference - libraries: - - ------------------------------------------------------------------------------ --- | --- Module : module --- Copyright : (c) author year --- License : license --- --- Maintainer : libraries@haskell.org | email-address --- Stability : experimental | provisional | stable --- Portability : portable | non-portable (reason(s)) --- --- $Id$ --- --- Description ------------------------------------------------------------------------------ - - - where: - - - - $Id: libraries.xml,v 1.2 2004/08/18 16:42:56 panne Exp $ - - is optional, but may be included if the module is - under CVS or RCS control (however, current wisdom - suggests that using - $Id$ tags are not such - a great idea). - - - - - module - - is the fully qualified module name of the - module - - - - - author/year - - Is the primary author and copyright holder of the - module, and the year in which copyright is - claimed. - - - - - license - - Specifies the license on the file (see ). - - - - - email-address - - The email address of the maintainer, or - maintainers, of the library (see ). - - - - - reason(s) - - The reasons for non-portability must be listed - (see ). - - - - - description - - A short description of the module. - - - - - - - - Testing - ToDo - - - - - Migration path - - How compatible will a compiler using the new libraries be - with code written for Haskell 98 or older library systems (such as - the hslibs suite and GHC's package system), and - for how long will compatibility be maintained? - - Our current plan for GHC is as follows: by default, with the - flag, you'll get access to the - following libraries from the CVS repository: those under - base, network, - unix, readline, - template-haskell, and - haskell-src. Compatibility with Haskell 98 - code will be maintained using a separate package of wrappers - presenting interfaces for the Haskell 98 libraries - (IO, Ratio, - Directory, etc.). The Haskell 98 compatibility - package will be enabled by default, but we plan to add an option - to disable it if necessary. For code that uses -package - lang, we could also provide a compatibility wrapper - package (so -package lang will continue to work - as before and present the same library interfaces), but this may - prove too much work to maintain - we haven't decided whether to do - this or not. It is unlikely that compatibility wrappers for any - of the other hslibs packages will be - provided. - - - - Library design - - - Naming conventions - - These naming conventions are pulled straight from the - hslibs documentation. They were formed after - lengthy discussions and are heavily based on an initial - suggestion from Marcin Kowalczyk - qrczak@knm.org.pl. - - Note that the conventions are not mutually exclusive, - e.g. should the function creating a set from a list of elements - have the name set or - listToSet? (Alas, it currently has neither - name.) - - The following nomenclature is used: Pure, - i.e. non-monadic functions are simply called, well, - functions. Monadic functions, - i.e. functions having a type ... -> m a - for some Monad m are called - actions. - - - Constructor names - Constructor names - - - - Empty values of type X - have the name emptyX, - e.g. emptySet. - - - - Actions creating a new empty value of type - X have the name - newEmptyX, - e.g. newEmptyMVar. - - - - Functions creating an arbitrary value of type - X have the name - X itself (with the first letter - downcased), - e.g. array. (TODO: - This often collides with xToY - convention, how should this be resolved?) - - - - - Actions creating new values arbitrary values of type - X have the name - newX, - e.g. newIORef. - - - - - - - Accessor names - Accessor names - - - - Functions getting an attribute of a value or a part - of it have the name of the attribute itself, - e.g. length, bounds. - - - - - Actions accessing some kind of reference or state - have the name - getX, where - X is the type of the contents - or the name of the part being accessed, - e.g. getChar, - getEnv. An alternative naming scheme is - readY, - where Y is the type of the - reference or container, e.g. readIORef. - - - - - Functions or actions getting a value via a - pointer-like type X should be - named - deRefX, - e.g. deRefStablePtr, - deRefWeak. - - - - - - Modifier names - Modifier names - - - - Functions returning a value with attribute - X set to a new value should be - named - setX. (TODO: - Add Examples.) - - - - Actions setting some kind of reference or state - have the name - putX, where - X is the type of the contents - or the name of the part being accessed, - e.g. putChar. An alternative naming - scheme is - writeY, - where X is the type of the - reference or container, - e.g. writeIORef. - - - Actions in the IO monad setting - some global state X are - traditionally named setX, too, although - putX would - be more appropriate, - e.g. setReadlineName. - - - - Actions modifying a container - X by a function of type - a -> a have the name - modifyX, - e.g. modifySTRef. - - - - - - Predicate names - Predicate names - - - - Predicates, both non-monadic and monadic, testing a - property X have the name - isX. - - - - - - - Names for conversions - Names for conversions - - - - Functions converting a value of type - X to a value of type - Y have the name - XToY - with all leading uppercase characters of - X converted to lower case, - e.g. stToIO. - - - - Overloaded conversion functions of type - C a => a -> X - have the name - toX, - e.g. toInteger. - - - - Overloaded conversion functions of type -C a => X -> a - have the name fromX, -e.g. fromInteger. - - - - - - Miscellaneous naming conventions - Miscellaneous naming - conventions - - - - An action that is identical to another one called - X, but discards the return - value has the name - X_, - e.g. mapM and mapM_. - - - - - Functions and actions which are potentially - dangerous to use and leave some kind of proof obligation - to the programmer have the name - unsafeX, - e.g. unsafePerformIO. - - - - - There are two conventions for binary and N-ary - variants of an associative operation: One convention uses - an operator or a short name for the binary operation and a - long name for the N-ary variant, - e.g. (+) and sum, - max and maximum. The - other convention suffixes the N-ary variant with - Many. (TODO: Add - Examples.) - - - - If possible, names are chosen such that either plain - application or arg1 `operation` arg2 is - correct English, e.g. isPrefixOf is - good for use in backquotes. - - - - - - - Library design guidelines - - - - Actions setting and modifying a kind of reference or - state return (), getting the value is - separate, e.g. writeIORef and - modifyIORef both return - (), only readIORef - returns the value in an IORef - - - - - A function or action taking a some kind of state and - returning a pair consisting of a result and a new state, the - result is the first element of the pair and the new state is - the second, see e.g. Random. - - - - When the type Either is used to - encode an error condition and a normal result, - Left is used for the former and - Right for the latter, see - e.g. Control.Monad.Error. - - - - A module corresponding to a class - (e.g. Bits) contains the class - definition, perhaps some auxiliary functions, and all - sensible instances for Prelude types, but nothing - more. Other modules containing types for which an instance - for the class in question makes sense contain the code for - the instance itself. - - - - Record-like C bit fields or structs have a - record-like interface, i.e. pure getting and setting of - fields. (TODO: Clarify a little - bit. Add examples.) - - - - Although the possibility of partial application - suggests the type - -attr -> object -> object - - for functions setting an attribute or value, infix notation - with backquotes implies - -object -> attr -> object. - - (TODO: Add Examples.) - - - - Conditional interfaces: a library interface should - vary between versions of the library only, not between - platforms or Haskell implementations. Such differences may - be visible at the module level only, so for example module - System.Win32 would be available on Win32 - systems only, and GHC.Exts would only be - available when compiling with GHC. - - - - - - - - Changes to standard Haskell 98 libraries - - Some changes have been made to the standard Haskell 98 - libraries in the new library scheme, both in the names of the - modules themselves and in their exported interfaces. Below is a - summary of those changes - at this time, the new libraries are - marked as provisional and are maintained by - libraries@haskell.org, so changes in the interfaces - are all up for discussion. - - -modules with interface changes ------------------------------- - -Array -> Data.Array - added instance Typeable (Array ix a) - -Char -> Data.Char - no interface changes (should have instance Typeable?) - -Complex -> Data.Complex - added instance Typeable (Complex a) - -IO -> System.IO - added - hPutBuf :: Handle -> Ptr a -> Int -> IO () - hGetBuf :: Handle -> Ptr a -> Int -> IO Int - fixIO :: (a -> IO a) -> IO a - hSetEcho :: Handle -> Bool -> IO () - hGetEcho :: Handle -> IO Bool - hIsTerminalDevice :: Handle -> IO Bool - -List -> Data.List - exports [](..) - -System -> System.Exit, System.Environment, System.Cmd - split into three modules - -just renamed, no interface changes: ------------------------------------ - -CPUTTime -> System.CPUTime -Directory -> System.IO.Directory -Ix -> Data.Ix -Locale -> System.Locale -Maybe -> Data.Maybe -Monad -> Data.Monad -Numeric -> Numeric -Random -> System.Random -Ratio -> Data.Ratio -Time -> System.Time - - - -
diff --git a/libraries/doc/libtable.xml b/libraries/doc/libtable.xml deleted file mode 100644 index 5caf44a..0000000 --- a/libraries/doc/libtable.xml +++ /dev/null @@ -1,815 +0,0 @@ - -Control.Arrow -ross@soi.city.ac.uk -Arrow.hs - - -Control.Concurrent -libraries@haskell.org -Concurrent.hs - - -Control.Concurrent.Chan -libraries@haskell.org -Chan.hs - - -Control.Concurrent.MVar -libraries@haskell.org -MVar.hs - - -Control.Concurrent.QSem -libraries@haskell.org -QSem.hs - - -Control.Concurrent.QSemN -libraries@haskell.org -QSemN.hs - - -Control.Concurrent.SampleVar -libraries@haskell.org -SampleVar.hs - - -Control.Exception -libraries@haskell.org -Exception.hs - - -Control.Monad -libraries@haskell.org -Monad.hs - - -Control.Monad.Cont -libraries@haskell.org -Cont.hs - - -Control.Monad.Error -libraries@haskell.org -Error.hs - - -Control.Monad.Fix -libraries@haskell.org -Fix.hs - - -Control.Monad.Identity -libraries@haskell.org -Identity.hs - - -Control.Monad.List -libraries@haskell.org -List.hs - - -Control.Monad.Reader -libraries@haskell.org -Reader.hs - - -Control.Monad.RWS -libraries@haskell.org -RWS.hs - - -Control.Monad.State -libraries@haskell.org -State.hs - - -Control.Monad.ST -libraries@haskell.org -ST.hs - - -Control.Monad.ST.Lazy -libraries@haskell.org -Lazy.hs - - -Control.Monad.ST.Strict -libraries@haskell.org -Strict.hs - - -Control.Monad.Trans -libraries@haskell.org -Trans.hs - - -Control.Monad.Writer -libraries@haskell.org -Writer.hs - - -Control.Parallel -libraries@haskell.org -Parallel.hs - - -Control.Parallel.Strategies -libraries@haskell.org -Strategies.hs - - -Data.Array -libraries@haskell.org -Array.hs - - -Data.Array.Base -libraries@haskell.org -Base.hs - - -Data.Array.Diff -libraries@haskell.org -Diff.hs - - -Data.Array.IArray -libraries@haskell.org -IArray.hs - - -Data.Array.IO -libraries@haskell.org -IO.hs - - -Data.Array.IO.Internal -libraries@haskell.org -Internals.hs - - -Data.Array.MArray -libraries@haskell.org -MArray.hs - - -Data.Array.ST -libraries@haskell.org -ST.hs - - -Data.Array.Storable -libraries@haskell.org -Storable.hs - - -Data.Array.Unboxed -libraries@haskell.org -Unboxed.hs - - -Data.Bits -libraries@haskell.org -Bits.hs - - -Data.Bool -libraries@haskell.org -Bool.hs - - -Data.Char -libraries@haskell.org -Char.hs - - -Data.Complex -libraries@haskell.org -Complex.hs - - -Data.Dynamic -libraries@haskell.org -Dynamic.hs - - -Data.Either -libraries@haskell.org -Either.hs - - -Data.FiniteMap -libraries@haskell.org -FiniteMap.hs - - -Data.Generics -libraries@haskell.org -Generics.hs - - -Data.Graph -libraries@haskell.org -Graph.hs - - -Data.HashTable -libraries@haskell.org -HashTable.hs - - -Data.Int -libraries@haskell.org -Int.hs - - -Data.IORef -libraries@haskell.org -IORef.hs - - -Data.Ix -libraries@haskell.org -Ix.hs - - -Data.List -libraries@haskell.org -List.hs - - -Data.Maybe -libraries@haskell.org -Maybe.hs - - -Data.Monoid -libraries@haskell.org -Monoid.hs - - -Data.PackedString -libraries@haskell.org -PackedString.hs - - -Data.Ratio -libraries@haskell.org -Ratio.hs - - -Data.Set -libraries@haskell.org -Set.hs - - -Data.STRef -libraries@haskell.org -STRef.hs - - -Data.STRef.Lazy -libraries@haskell.org -Lazy.hs - - -Data.STRef.Strict -libraries@haskell.org -Strict.hs - - -Data.Tree -libraries@haskell.org -Tree.hs - - -Data.Tuple -libraries@haskell.org -Tuple.hs - - -Data.Unique -libraries@haskell.org -Unique.hs - - -Data.Word -libraries@haskell.org -Word.hs - - -Debug.QuickCheck -libraries@haskell.org -QuickCheck.hs - - -Debug.QuickCheck.Batch -libraries@haskell.org -Batch.hs - - -Debug.QuickCheck.Poly -libraries@haskell.org -Poly.hs - - -Debug.QuickCheck.Utils -libraries@haskell.org -Utils.hs - - -Debug.Trace -libraries@haskell.org -Trace.hs - - -DSP (hierarchy) -Matthew Donadio m.p.donadio@ieee.org -Proposal - - -Foreign -ffi@haskell.org -Foreign.hs - - -Foreign.C -ffi@haskell.org -C.hs - - -Foreign.C.Error -ffi@haskell.org -Error.hs - - -Foreign.C.String -ffi@haskell.org -String.hs - - -Foreign.C.Types -ffi@haskell.org -Types.hs - - -Foreign.Concurrent -ffi@haskell.org -Concurrent.hs - - -Foreign.ForeignPtr -ffi@haskell.org -ForeignPtr.hs - - -Foreign.Marshal -ffi@haskell.org -Marshal.hs - - -Foreign.Marshal.Alloc -ffi@haskell.org -Alloc.hs - - -Foreign.Marshal.Array -ffi@haskell.org -Array.hs - - -Foreign.Marshal.Error -ffi@haskell.org -Error.hs - - -Foreign.Marshal.Pool -sven.panne@aedion.de -Pool.hs - - -Foreign.Marshal.Utils -ffi@haskell.org -Utils.hs - - -Foreign.Ptr -ffi@haskell.org -Ptr.hs - - -Foreign.StablePtr -ffi@haskell.org -StablePtr.hs - - -Foreign.Storable -ffi@haskell.org -Storable.hs - - -Graphics.HGL (hierarchy) -Alastair Reidreid-consulting-uk.ltd.uk -HGL.hs - - -Graphics.Rendering.OpenGL (hierarchy) -sven.panne@aedion.de -OpenGL.hs - - -Graphics.UI.GLUT (hierarchy) -sven.panne@aedion.de -GLUT.hs - - -Graphics.UI.ObjectIO (hierarchy) -ka2_mail@yahoo.com -ObjectIO.hs - - -Graphics.X11 (hierarchy) -Alastair Reidreid-consulting-uk.ltd.uk -X11.hs - - -Language.Haskell.Lexer -libraries@haskell.org -Lexer.hs - - -Language.Haskell.ParseMonad -libraries@haskell.org -ParseMonad.hs - - -Language.Haskell.Parser -libraries@haskell.org -Parser.hs - - -Language.Haskell.ParseUtils -libraries@haskell.org -ParseUtils.hs - - -Language.Haskell.Pretty -libraries@haskell.org -Pretty.hs - - -Language.Haskell.Syntax -libraries@haskell.org -Syntax.hs - - -Language.Haskell.TH -libraries@haskell.org -TH.hs - - -Language.Haskell.TH.Syntax -libraries@haskell.org -Syntax.hs - - -Language.Haskell.TH.Lib -libraries@haskell.org -Lib.hs - - -Language.Haskell.TH.Ppr -libraries@haskell.org -Ppr.hs - - -Language.Haskell.TH.PprLib -libraries@haskell.org -PprLib.hs - - -Network -libraries@haskell.org -Network.hs - - -Network.BSD -libraries@haskell.org -BSD.hsc - - -Network.CGI -libraries@haskell.org -CGI.hs - - -Network.Socket -libraries@haskell.org -Socket.hsc - - -Network.URI -libraries@haskell.org -URI.hs - - -Numeric -libraries@haskell.org -Numeric.hs - - -Prelude -libraries@haskell.org -Prelude.hs - - -System.Cmd -libraries@haskell.org -Cmd.hs - - -System.Console.GetOpt -libraries@haskell.org -GetOpt.hs - - -System.Console.Readline -libraries@haskell.org -Readline.hsc - - -System.CPUTime -libraries@haskell.org -CPUTime.hs - - -System.Directory -libraries@haskell.org -Directory.hs - - -System.Posix.DynamicLinker -vs@foldr.org -DynamicLinker.hsc - - -System.Posix.DynamicLinker.Prim -vs@foldr.org -Prim.hsc - - -System.Posix.DynamicLinker.Module -vs@foldr.org -Module.hsc - - -System.Environment -libraries@haskell.org -Environment.hs - - -System.Exit -libraries@haskell.org -Exit.hs - - -System.Info -libraries@haskell.org -Info.hs - - -System.IO -libraries@haskell.org -IO.hs - - -System.IO.Error -libraries@haskell.org -Error.hs - - -System.IO.Unsafe -libraries@haskell.org -Unsafe.hs - - -System.Locale -libraries@haskell.org -Locale.hs - - -System.Mem -libraries@haskell.org -Mem.hs - - -System.Mem.StableName -libraries@haskell.org -StableName.hs - - -System.Mem.Weak -libraries@haskell.org -Weak.hs - - -System.Posix -libraries@haskell.org -Posix.hs - - -System.Posix.Env -libraries@haskell.org -Env.hs - - -System.Posix.Files -libraries@haskell.org -Files.hs - - -System.Posix.Internals -cvs-ghc@haskell.org -Internals.hs - - -System.Posix.IO -libraries@haskell.org -IO.hs - - -System.Posix.Process -libraries@haskell.org -Process.hs - - -System.Posix.Resource -libraries@haskell.org -Resource.hs - - -System.Posix.Terminal -libraries@haskell.org -Terminal.hs - - -System.Posix.Time -libraries@haskell.org -Time.hs - - -System.Posix.Unistd -libraries@haskell.org -Unistd.hs - - -System.Posix.User -libraries@haskell.org -User.hs - - -System.Posix.Signals -libraries@haskell.org -Signals.hs - - -System.Posix.Types -libraries@haskell.org -Types.hs - - -System.Random -libraries@haskell.org -Random.hs - - -System.Sendfile -vs@foldr.org -Sendfile.hsc - - -System.Time -libraries@haskell.org -Time.hs - - -System.Win32 -libraries@haskell.org -Win32.hs - - -Text.Html -Andy Gill andy@galconn.com -Html.hs - - -Text.Html.BlockTable -Andy Gill andy@galconn.com -BlockTable.hs - - -Text.ParserCombinators.Parsec -daan@cs.uu.nl -Parsec.hs - - -Text.ParserCombinators.Parsec.Char -daan@cs.uu.nl -Char.hs - - -Text.ParserCombinators.Parsec.Combinator -daan@cs.uu.nl -Combinator.hs - - -Text.ParserCombinators.Parsec.Error -daan@cs.uu.nl -Error.hs - - -Text.ParserCombinators.Parsec.Expr -daan@cs.uu.nl -Expr.hs - - -Text.ParserCombinators.Parsec.Language -daan@cs.uu.nl -Language.hs - - -Text.ParserCombinators.Parsec.Perm -daan@cs.uu.nl -Perm.hs - - -Text.ParserCombinators.Parsec.Pos -daan@cs.uu.nl -Pos.hs - - -Text.ParserCombinators.Parsec.Prim -daan@cs.uu.nl -Prim.hs - - -Text.ParserCombinators.Parsec.Token -daan@cs.uu.nl -Token.hs - - -Text.ParserCombinators.ReadP -libraries@haskell.org -ReadP.hs - - -Text.ParserCombinators.ReadPrec -libraries@haskell.org -ReadPrec.hs - - -Text.PrettyPrint -libraries@haskell.org -PrettyPrint.hs - - -Text.PrettyPrint.HughesPJ -libraries@haskell.org -HughesPJ.hs - - -Text.Read -libraries@haskell.org -Read.hs - - -Text.Read.Lex -libraries@haskell.org -Lex.hs - - -Text.Regex -libraries@haskell.org -Regex.hs - - -Text.Regex.Posix -libraries@haskell.org -Posix.hs - - -Text.Show -libraries@haskell.org -Show.hs - - -Text.Show.Functions -libraries@haskell.org -Functions.hs - - -Text.XML.HaXml (hierarchy) -Malcolm.Wallace@cs.york.ac.uk -HaXml - -- 1.7.10.4