[project @ 2001-07-31 11:51:09 by simonmar]
Catch up with changes in the main tree.

[project @ 2001-07-05 13:52:49 by simonmar]
Latest revisions:

  - the language extension proposal is included, importing a slightly
    edited version of Malcolm's original proposal.  The section on
    'implicit as' is placed under a "possible extension" section
    heading, as we haven't come to a conclusion on this yet.

  - Note proposal to rename Org to Contrib

  - Add hierarchy design guidelines

  - Rename NHC to Nhc consistently

  - Elaborate on what we mean by "approved extensions" in the
    portability section.

[project @ 2001-07-05 10:38:33 by simonmar]
Makefile for the document.

[project @ 2001-07-04 12:07:27 by simonmar]
Add Numeric library here for the time being.  This is a combination of
the H98 Numeric library and a few functions from GHC's NumExts.

[project @ 2001-07-04 12:06:33 by simonmar]
Add
showListWith :: (a -> ShowS) -> [a] -> ShowS

from GHC's NumExts library.

[project @ 2001-07-04 11:30:52 by simonmar]
Add Prelude imports.

[project @ 2001-07-04 11:29:26 by simonmar]
need to import Data.Tuple explicitly to get dependencies right.

[project @ 2001-07-04 11:06:39 by simonmar]
Add Generics library

[project @ 2001-07-04 10:51:09 by simonmar]
oops, better import Prelude

(we have to explicitly import Prelude in all modules that aren't
compiled with -fno-implicit-prelude so that ghc --make gets the
dependencies right.  This should really be fixed in CompManager
somehow).

[project @ 2001-07-04 10:48:39 by simonmar]
Add 4 new libraries

[project @ 2001-07-04 10:48:16 by simonmar]
bugfix in yesterday's changes.

[project @ 2001-07-03 14:17:23 by simonmar]
GHC.Maybe isn't used any more (contents moved to Data.Maybe and Data.Either).

[project @ 2001-07-03 14:13:32 by simonmar]
Move generic Maybe and Either definitions from GHC.Maybe to Data.Maybe
and Data.Either, and remove GHC.Maybe.

[project @ 2001-07-03 11:38:07 by simonmar]
add new file

[project @ 2001-07-03 11:37:49 by simonmar]
Latest round of changes, incorporating:

  - some changes to the portability/stability requested by Malcolm
  - Control.Monad.Fix is portable, IO/ST instances moved to System.IO,
    Control.Monad.ST respectively.
  - GHC.Tup moved to Data.Tuple, the code in here is mostly portable
    (and the interface better be).

[project @ 2001-07-03 09:21:46 by simonmar]
Add a paragraph on when to pluralize(*) a module name

(*) it's a word, I checked

[project @ 2001-07-03 09:02:05 by simonmar]
add paragraph about capitalisation of module names

[project @ 2001-06-29 09:44:03 by simonmar]
merge ghc/lib/std/CPUTime.hsc rev. 1.7

[project @ 2001-06-29 09:41:37 by simonmar]
merge fptools/hslibs/lang/ST.lhs rev. 1.4

[project @ 2001-06-28 14:15:04 by simonmar]
First cut of the Haskell Core Libraries
=======================================

NOTE: it's not meant to be a working snapshot.  The code is just here
to look at and so the NHC/Hugs guys can start playing around with it.

There is no build system.  For GHC, the libraries tree is intended to
be grafted onto an existing fptools/ tree, and the Makefile in
libraries/core is a quick hack for that setup.  This won't work at the
moment without the other changes needed in fptools/ghc, which I
haven't committed because they'll cause breakage.  However, with the
changes required these sources build a working Prelude and libraries.

The layout mostly follows the one we agreed on, with one or two minor
changes; in particular the Data/Array layout probably isn't final
(there are several choices here).

The document is in libraries/core/doc as promised.

The cbits stuff is just a copy of ghc/lib/std/cbits and has
GHC-specific stuff in it.  We should really separate the
compiler-specific C support from any compiler-independent C support
there might be.

Don't pay too much attention to the portability or stability status
indicated in the header of each source file at the moment - I haven't
gone through to make sure they're all consistent and make sense.

I'm using non-literate source outside of GHC/.  Hope that's ok with
everyone.

We need to discuss how the build system is going to work...