Specify the build-type and min cabal-version.
Don't have Data.Array in both exposed-modules on both sides of a
conditional, just make it unconditional.
Stop using -fglasgow-exts and specify all the extensions explicitly.
Some extensions are conditional on non-nhc98 and some are ghc-specific.

The real reason to not import Control.Applicative is that it exports
the non-H98 instance Functor ((->) a) and it is important for
Data.Array to not re-export that because the H98 Array module
re-exports bits of Data.Array and it is vital that we do not export
non-H98 instances from a module specified in H98.

This is a divergence from Haskell 98.
 * Add (numElements :: Ix i => a i e -> Int) to IArray class
 * Array types get an extra field for numElements, e.g.
   {{{
   -data UArray i e = UArray !i !i ByteArray#
   +data UArray i e = UArray !i !i !Int ByteArray#
   }}}
   This is a cache of rangeSize(l,u)
 * Add safeRangeSize (always returns >= 0)
 * Add safeIndex (use unsafeIndex (no Ix inRange check),
                  but check index < numElements)
 * unsafeForeignPtrToStorableArray gained an (Ix i) context

A recent patch to System.IO introduced a cyclic dependency on Foreign.C.Error,
and also inadvertently dragged along System.Posix.Internals which has
non-H'98 layout, causing many build problems.  The solution for now
is to #ifndef __NHC__ all of the recent the openTempFile additions,
and mark them non-portable once again.  (I also took the opportunity
to note a number of other non-portable functions in their Haddock
comments.)

I have not looked at the details, but the type checker is happy with the
more general type, and more general types are usually a Good Thing.

The old setmode code was throwing an exception, and I'm not sure it is
meant to do what we need anyway. For now we assume that all FDs are
both readable and writable.

Not just on Windows.  This change is required because we now use safe
foreign calls for I/O on blocking file descriptors with the threaded
RTS.  Exposed by concio001.thr on MacOS X: MacOS apparently uses
smaller buffers by default, so they weren't being allocated as large
objects.

The name collision with System.Posix.IO.openFd made my brain hurt.

See http://haskell.org/pipermail/libraries/2007-July/007785.html for a piece
of code triggering the bug. updateAt threw away parts of the tree making up
the map.

This helps reduce the memory requirements for a closed but unfinalised
Handle.