1{-# LANGUAGE CPP #-}
2
3-----------------------------------------------------------------------------
4-- |
5-- Module      :  Control.Parallel
6-- Copyright   :  (c) The University of Glasgow 2001
7-- License     :  BSD-style (see the file libraries/base/LICENSE)
8--
9-- Maintainer  :  libraries@haskell.org
10-- Stability   :  stable
11-- Portability :  portable
12--
13-- Parallel Constructs
14--
15-----------------------------------------------------------------------------
16
17module Control.Parallel (
18          par, pseq
19    ) where
20
21#ifdef __GLASGOW_HASKELL__
22import qualified GHC.Conc       ( par, pseq )
23
24infixr 0 `par`, `pseq`
25#endif
26
27-- Maybe parIO and the like could be added here later.
28
29-- | Indicates that it may be beneficial to evaluate the first
30-- argument in parallel with the second.  Returns the value of the
31-- second argument.
32--
33-- @a ``par`` b@ is exactly equivalent semantically to @b@.
34--
35-- @par@ is generally used when the value of @a@ is likely to be
36-- required later, but not immediately.  Also it is a good idea to
37-- ensure that @a@ is not a trivial computation, otherwise the cost of
38-- spawning it in parallel overshadows the benefits obtained by
39-- running it in parallel.
40--
41-- Note that actual parallelism is only supported by certain
42-- implementations (GHC with the @-threaded@ option, and GPH, for
43-- now).  On other implementations, @par a b = b@.
44--
45par :: a -> b -> b
46#ifdef __GLASGOW_HASKELL__
47par = GHC.Conc.par
48#else
49-- For now, Hugs does not support par properly.
50par a b = b
51#endif
52
53-- | Semantically identical to 'seq', but with a subtle operational
54-- difference: 'seq' is strict in both its arguments, so the compiler
55-- may, for example, rearrange @a ``seq`` b@ into @b ``seq`` a ``seq`` b@.
56-- This is normally no problem when using 'seq' to express strictness,
57-- but it can be a problem when annotating code for parallelism,
58-- because we need more control over the order of evaluation; we may
59-- want to evaluate @a@ before @b@, because we know that @b@ has
60-- already been sparked in parallel with 'par'.
61--
62-- This is why we have 'pseq'.  In contrast to 'seq', 'pseq' is only
63-- strict in its first argument (as far as the compiler is concerned),
64-- which restricts the transformations that the compiler can do, and
65-- ensures that the user can retain control of the evaluation order.
66--
67pseq :: a -> b -> b
68#ifdef __GLASGOW_HASKELL__
69pseq = GHC.Conc.pseq
70#else
71pseq = seq
72#endif
73