<para>where currently the syntax is</para>
<programlisting>
- modid -> conid
+ modid -> conid
qconid -> [modid .] conid
</programlisting>
<para>We first classify each node in the hierarchy according to
one of the following terms:</para>
+ ToDo: unpublished interfaces.
+
<variablelist>
<varlistentry>
<term>Allocated</term>
<para>The <literal>User</literal> 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 the <literal>@</literal> by a <literal>.</literal>,
- reverse the order of the components, capitalise the first
- letter of each component, and prepend
- <literal>User.</literal>. For example,
+ replace any <quote><literal>.</literal></quote>s in the
+ username (before the <literal>@</literal>) with
+ <quote><literal>_</literal></quote>, replace the
+ <quote><literal>@</literal></quote> by a
+ <quote><literal>.</literal></quote>, reverse the order of
+ the components, capitalise the first letter of each
+ component, and prepend
+ <quote><literal>User.</literal></quote>. For example,
<literal>simonmar@microsoft.com</literal> becomes
<literal>User.Com.Microsoft.Simonmar</literal>.</para>
</listitem>
are never grouped by standards compliance, portability,
stability, or any other property.</para>
</blockquote>
+
+ <para>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 <literal>Text</literal>
+ hierarchy could logically be placed as a child of
+ <literal>FileFormat</literal>, we choose not to because
+ <literal>Text</literal> is ubiquitous and we don't want to have
+ to type the extra component all the time.</para>
+
+ <para>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
+ <literal>Language.Haskell</literal> we have children
+ <literal>Syntax</literal>, <literal>Lexer</literal>,
+ <literal>Parser</literal> etc., so under
+ <literal>Language.C</literal> we should have a similar
+ structure.</para>
</sect2>
<sect2 id="module-naming-convention">
<itemizedlist>
<listitem>
<para>A module defining a data type or type class
- <replaceable>X</replaceable> has the itself the name
+ <replaceable>X</replaceable> has itself the name
<replaceable>X</replaceable>, e.g.
<literal>StablePtr</literal>.</para>
</listitem>
would be named <literal>M.Internals</literal>. eg.</para>
<programlisting>
-import Text.Html -- The library
-import Text.Html.Internals -- The non-abstract library (for building other libs)
+import Text.HTML -- The library
+import Text.HTML.Internals -- The non-abstract library
</programlisting>
</listitem>
<literal>Foreign</literal>, <emphasis>ToDo: what
else?</emphasis>.</para>
+ <para>There is one further requirement: only licenses approved by
+ the Open Source Initiative may be used with the core libraries.
+ See <ulink url="http://www.opensource.org//">The Open Source
+ Initiative</ulink> for a list of approved licensees.</para>
+
<para><emphasis>ToDo: include a prototype BSD license
here</emphasis>.</para>
</sect1>
-
+
<sect1 id="versioning">
<title>Versioning</title>
<para></para>
</itemizedlist>
<para>Extensions which we'd like to be standard, but aren't
- currently implemented by one or more of the our target
+ currently implemented by one or more of the target
compilers:</para>
<itemizedlist>
</listitem>
<listitem>
<para>Concurrent Haskell (pre-emptive multitasking
- optional). Hugs implements this, but Nhc currently does
- not.</para>
+ optional). GHC and Hugs implement this, but Nhc currently
+ does not.</para>
</listitem>
</itemizedlist>
<para>The following extensions are not likely to become part of
the baseline, but are nevertheless used by one or more libraries
- in the core set:</para>
+ in the core set (which are thus designated non-portable):</para>
<itemizedlist>
<listitem>
</listitem>
<listitem>
<para>Manage any discussion related to the library (which can
- take place on <email>libraries.haskell.org</email> if
+ take place on <email>libraries@haskell.org</email> if
necessary), and summarise the results. Make final decisions,
and implement them.</para>
</listitem>
-- Stability : experimental | provisional | stable
-- Portability : portable | non-portable (<replaceable>reason(s)</replaceable>)
--
--- $Id: libraries.sgml,v 1.4 2001/07/05 13:52:49 simonmar Exp $
+-- $Id: libraries.sgml,v 1.8 2002/06/11 10:53:03 simonmar Exp $
--
-- <replaceable>Description</replaceable>
-----------------------------------------------------------------------------
<variablelist>
<varlistentry>
- <term><literal>$Id: libraries.sgml,v 1.4 2001/07/05 13:52:49 simonmar Exp $</literal></term>
+ <term><literal>$Id: libraries.sgml,v 1.8 2002/06/11 10:53:03 simonmar Exp $</literal></term>
<listitem>
<para>is optional, but usually included if the module is
under CVS or RCS control.</para>
encode an error condition and a normal result,
<literal>Left</literal> is used for the former and
<literal>Right</literal> for the latter, see
- e.g. <literal>MonadEither</literal>.</para>
+ e.g. <literal>Control.Monad.Error</literal>.</para>
</listitem>
<listitem>
- <para> A module corresponding to a class
+ <para>A module corresponding to a class
(e.g. <literal>Bits</literal>) contains the class
definition, perhaps some auxiliary functions, and all
sensible instances for Prelude types, but nothing
</listitem>
<listitem>
- <para> Record-like C bit fields or structs have a
+ <para>Record-like C bit fields or structs have a
record-like interface, i.e. pure getting and setting of
fields. (<emphasis>TODO</emphasis>: Clarify a little
bit. Add examples.)</para>
</listitem>
<listitem>
- <para> Although the possibility of partial application
+ <para>Although the possibility of partial application
suggests the type
<literal><replaceable>attr</replaceable> -> <replaceable>object</replaceable> -> <replaceable>object</replaceable></literal>
IO -> System.IO
added
- hPutBuf :: Handle -> Ptr a -> Int -> IO ()
- hGetBuf :: Handle -> Ptr a -> Int -> IO Int
- fixIO :: (a -> IO a) -> IO a
+ 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 [](..)
- Numeric -> Numeric
- added showHex, showOct, showBin & showIntAtBase from NumExts,
- but left out floatToDouble & doubleToFloat (realToFrac is more general).
-
System -> System.Exit, System.Environment, System.Cmd
split into three modules
Directory -> System.IO.Directory
Ix -> Data.Ix
Locale -> System.Locale
+ Maybe -> Data.Maybe
Monad -> Data.Monad
- Random -> System.Radom
+ Numeric -> Numeric
+ Random -> System.Random
Ratio -> Data.Ratio
Time -> System.Time
</screen>
projects / ghc-base.git / blobdiff