GitLab

When `readMVar` was implemented using `takeMVar` and `putMVar`,
we needed to use `modifyMVarMasked` in `readChan` just in case
the `readMVar` was interrupted between taking and putting. Now
that `readMVar` uses an atomic primop, this is impossible, so we can
safely unmask `readMVar`.

Reviewers: hvr, bgamari, simonmar

Reviewed By: simonmar

Subscribers: rwbarton, thomie, carter

Differential Revision: https://phabricator.haskell.org/D4738

Test Plan: ./validate

Reviewers: hvr, goldfire, bgamari, RyanGlScott

Reviewed By: RyanGlScott

Subscribers: rwbarton, thomie, carter

GHC Trac Issues: #11767

Differential Revision: https://phabricator.haskell.org/D4452

Removes isEmptyChan and unGetChan, which have been deprecated for a very
long time. See #13561.

Test Plan: Validate

Reviewers: austin, hvr

Subscribers: rwbarton, thomie

GHC Trac Issues: #13561

Differential Revision: https://phabricator.haskell.org/D4060

- Mention that the read end is an `MVar`, so fairness guarantees are
  inherited.

- Mention that it can throw `BlockedIndefinitelyOnMVar` exception.

Reviewers: austin, hvr, bgamari

Reviewed By: bgamari

Subscribers: rwbarton, thomie

GHC Trac Issues: #5466

Differential Revision: https://phabricator.haskell.org/D3439

These are implemented using `MVars` which have known caveats. Suggest
the use of `TChan` from the stm library instead.

Test Plan: n/a

Reviewers: austin, hvr, bgamari

Reviewed By: bgamari

Subscribers: thomie

Differential Revision: https://phabricator.haskell.org/D2047

Thanks to #9858 `Typeable` doesn't need to be explicitly derived anymore.
This also makes `AutoDeriveTypeable` redundant, as well as some imports of
`Typeable` (removal of whose may be beneficial to #9707). This commit
removes several such now redundant use-sites in `base`.

Reviewed By: austin, ekmett

Differential Revision: https://phabricator.haskell.org/D712

Since they're implied by the lack of `NoImplicitPrelude`

This is a first step towards addressing #9111

This results in the following additional Typeable (exported) instances
being generated (list was compiled by diff'ing hoogle txt output):

  instance Typeable CFile
  instance Typeable 'CFile
  instance Typeable CFpos
  instance Typeable 'CFpos
  instance Typeable CJmpBuf
  instance Typeable 'CJmpBuf
  instance Typeable ChItem
  instance Typeable QSem
  instance Typeable ID
  instance Typeable 'ID
  instance Typeable CONST
  instance Typeable Qi
  instance Typeable Qr
  instance Typeable Mp
  instance Typeable ConstrRep
  instance Typeable Fixity
  instance Typeable 'Prefix
  instance Typeable 'Infix
  instance Typeable Constr
  instance Typeable DataType
  instance Typeable DataRep
  instance Typeable Data
  instance Typeable HasResolution
  instance Typeable IsList
Signed-off-by: Herbert Valerio Riedel <hvr@gnu.org>

This fixes the markup at the top of `Control.Arrow`, and improves the
markup inside DEPRECATED strings.

(Haddock supports markup inside DEPRECATED messages, which allows to
turn references to Haskell entities into hyperlinks by using the usual
Haddock markup.)
Signed-off-by: Herbert Valerio Riedel <hvr@gnu.org>

With GHC 7.8's PolyKinds the macros in `<Typeable.h>` are no longer of any
use, and their use is clearly obsolete. The sites using those macros are
replaced by auto-derivations of `Typeable` instances.

This reduces reliance on the CPP extension and the compile dependency on
`Typeable.h` in a couple of modules.
Signed-off-by: Herbert Valerio Riedel <hvr@gnu.org>

Now that HUGS and NHC specific code has been removed, this commit "folds"
the now redundant `#if((n)def)`s containing `__GLASGOW_HASKELL__`.  This
renders `base` officially GHC only.

This commit also removes redundant `{-# LANGUAGE CPP #-}`.
Signed-off-by: Herbert Valerio Riedel <hvr@gnu.org>

These comments are rather less useful now that haddock can give docs
with the same informatino in the module synopsis.

Having to maintain them when making changes to the library is a pain,
and when people forget about doing so there is nothing that checks that
the comments are right, so mistakes tend to linger.

Of the comments that my script detected, 78 of 684 were already
incorrect in one way or another, e.g. missing context:
    Text.Show.showsPrec
    Comment type: Int -> a -> ShowS
    Actual type:  Show a => Int -> a -> ShowS
wrong context:
    Numeric.readInt
    Comment type: Integral a => a -> (Char -> Bool) -> (Char -> Int) -> ReadS a
    Actual type:  Num a => a -> (Char -> Bool) -> (Char -> Int) -> ReadS a
not following a class change (e.g. Num losing its Eq superclass):
    Text.Read.Lex.readOctP
    Comment type: Num a => ReadP a
    Actual type:  (Eq a, Num a) => ReadP a
not following the Exceptions change:
    GHC.Conc.childHandler
    Comment type: Exception -> IO ()
    Actual type:  SomeException -> IO ()
or just always been wrong:
    GHC.Stable.deRefStablePtr
    Comment type: StablePtr a -> a
    Actual type:  StablePtr a -> IO a

As well as being more pleasant, this fixes #1841:
    Data.Typeable: Instances of basic types don't provide qualified
    strings to mkTyCon

Add explicit {-# LANGUAGE xxx #-} pragmas to each module, that say
what extensions that module uses.  This makes it clearer where
different extensions are used in the (large, variagated) base package.

Now base.cabal doesn't need any extensions field

Thanks to Bas van Dijk for doing all the work.

update non-portability reasons

Some more Typeable instances, as requested on the ghc-users list a while back.

IO.hGetContents ==> System.IO.hGetContents (in docs)

- Add documentation to Control.Concurrent and friends
- Other documentation tweaks

Rename libraries/core to libraries/base in the module headers.

Remove \$Id\$ from all files: it isn't particularly useful (see
previous discussion on cvs-ghc@haskell.org), and it confuses Haddock.

Add the single character '|' to the header comment of each module so
that Haddock will parse it as the module documentation.

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...