:: Monoid m => Bool -> m -> m -package:base

Like when, but operating on a Monoid. If the first argument is True returns the second, otherwise returns mempty.

mwhen True  "test" == "test"
mwhen False "test" == ""

\b m -> when b m == mfilter (const b) (m::Maybe Ordering)

\b m -> when b m == mfilter (const b) (m::String)

Returns the given value in case of the given predicate is satisfied (is True). Otherwise, it returns mempty.

>>> memptyIfFalse True (Just "Hello")
Just "Hello"

>>> memptyIfFalse False "Doesn't matter"
""

Returns the given value in case of the given predicate is unsatisfied (is False). Otherwise, it returns mempty.

>>> memptyIfTrue True (Just "Hello")
Nothing

>>> memptyIfTrue False "Does matter"
"Does matter"

Generalization of when.

Generalization of unless.

If the first argument evaluates to True, then the result is the second argument. Otherwise an AssertionFailed exception is raised, containing a String with the source file and line number of the call to assert. Assertions can normally be turned on or off with a compiler flag (for GHC, assertions are normally on unless optimisation is turned on with -O or the -fignore-asserts option is given). When assertions are turned off, the first argument to assert is ignored, and the second argument is returned as the result.

Like assert but is not removed by the compiler, it is always present in production code. Pre-release

Like assert, but only enabled with -fdebug-expensive-assertions. This function can be used for expensive assertions that should only be turned on during testing or debugging.

This is a valid definition of stimes for a Monoid. Unlike the default definition of stimes, it is defined for 0 and so it should be preferred where possible.

This is a valid definition of stimes for an idempotent Monoid. When mappend x x = x, this definition should be preferred, because it works in <math> rather than <math>

Repeat a value n times.

mtimesDefault n a = a <> a <> ... <> a  -- using <> (n-1) times

In many cases, `stimes 0 a` for a Monoid will produce mempty. However, there are situations when it cannot do so. In particular, the following situation is fairly common:

data T a = ...

class Constraint1 a
class Constraint1 a => Constraint2 a

instance Constraint1 a => Semigroup (T a) instance Constraint2 a => Monoid (T a) @ Since Constraint1 is insufficient to implement mempty, stimes for T a cannot do so. When working with such a type, or when working polymorphically with Semigroup instances, mtimesDefault should be used when the multiplier might be zero. It is implemented using stimes when the multiplier is nonzero and mempty when it is zero.

This is a valid definition of stimes for an idempotent Monoid. When x <> x = x, this definition should be preferred, because it works in <math> rather than <math>

Repeat a value n times.

mtimesDefault n a = a <> a <> ... <> a  -- using <> (n-1) times

In many cases, stimes 0 a for a Monoid will produce mempty. However, there are situations when it cannot do so. In particular, the following situation is fairly common:

data T a = ...

class Constraint1 a
class Constraint1 a => Constraint2 a

instance Constraint1 a => Semigroup (T a)
instance Constraint2 a => Monoid (T a)

Since Constraint1 is insufficient to implement mempty, stimes for T a cannot do so. When working with such a type, or when working polymorphically with Semigroup instances, mtimesDefault should be used when the multiplier might be zero. It is implemented using stimes when the multiplier is nonzero and mempty when it is zero.

Examples

>>> mtimesDefault 0 "bark"
[]

>>> mtimesDefault 3 "meow"
"meowmeowmeow"

Repeat a value n times.

mtimesDefault n a = a <> a <> ... <> a  -- using <> (n-1) times

Implemented using stimes and mempty. This is a suitable definition for an mtimes member of Monoid.

The value of seq a b is bottom if a is bottom, and otherwise equal to b. In other words, it evaluates the first argument a to weak head normal form (WHNF). seq is usually introduced to improve performance by avoiding unneeded laziness. A note on evaluation order: the expression seq a b does not guarantee that a will be evaluated before b. The only guarantee given by seq is that the both a and b will be evaluated before seq returns a value. In particular, this means that b may be evaluated before a. If you need to guarantee a specific order of evaluation, you must use the function pseq from the "parallel" package.

Indicates that it may be beneficial to evaluate the first argument in parallel with the second. Returns the value of the second argument. The result of a `par` b is always b, regardless of whether a evaluates to a bottom, so for example par undefined x = x. par is generally used when the value of a is likely to be required later, but not immediately. Also it is a good idea to ensure that a is not a trivial computation, otherwise the cost of spawning it in parallel overshadows the benefits obtained by running it in parallel. Note that actual parallelism is only supported by certain implementations (GHC with the -threaded option, for now). On other implementations, par a b = b.

Like seq but ensures that the first argument is evaluated before returning. a `pseq` b evaluates a to weak head normal form (WHNF) before returning b. This is similar to seq, but with a subtle difference: seq is strict in both its arguments, so the compiler may, for example, rearrange a `seq` b into b `seq` a `seq` b. This is normally no problem when using seq to express strictness, but it can be a problem when annotating code for parallelism, because we need more control over the order of evaluation; we may want to evaluate a before b, because we know that b has already been sparked in parallel with par. This is why we have pseq. In contrast to seq, pseq is only strict in its first argument (as far as the compiler is concerned), which restricts the transformations that the compiler can do, and ensures that the user can retain control of the evaluation order.