:: a -> a

Identity function.

id x = x

The call inline f arranges that f is inlined, regardless of its size. More precisely, the call inline f rewrites to the right-hand side of f's definition. This allows the programmer to control inlining from a particular call site rather than the definition site of the function (c.f. INLINE pragmas). This inlining occurs regardless of the argument to the call or the size of f's definition; it is unconditional. The main caveat is that f's definition must be visible to the compiler; it is therefore recommended to mark the function with an INLINABLE pragma at its definition so that GHC guarantees to record its unfolding regardless of size. If no inlining takes place, the inline function expands to the identity function in Phase zero, so its use imposes no overhead.

The call noinline f arranges that f will not be inlined. It is removed during CorePrep so that its use imposes no overhead (besides the fact that it blocks inlining.)

The lazy function restrains strictness analysis a little. The call lazy e means the same as e, but lazy has a magical property so far as strictness analysis is concerned: it is lazy in its first argument, even though its semantics is strict. After strictness analysis has run, calls to lazy are inlined to be the identity function. This behaviour is occasionally useful when controlling evaluation order. Notably, lazy is used in the library definition of par:

par :: a -> b -> b
par x y = case (par# x) of _ -> lazy y

If lazy were not lazy, par would look strict in y which would defeat the whole purpose of par.

Bring all regular text in a pandoc structure to uppercase. This function correctly handles cases where a lowercase character doesn't match to a single uppercase character – e.g. “Straße” would be converted to “STRASSE”, not “STRAßE”.

The identity function, returns the give value unchanged.

Renamed version of id.

>>> identity 10
10

>>> fmap identity [1,2,3]
[1,2,3]

The lazy function restrains strictness analysis a little. The call lazy e means the same as e, but lazy has a magical property so far as strictness analysis is concerned: it is lazy in its first argument, even though its semantics is strict. After strictness analysis has run, calls to lazy are inlined to be the identity function. This behaviour is occasionally useful when controlling evaluation order. Notably, lazy is used in the library definition of par:

par :: a -> b -> b
par x y = case (par# x) of _ -> lazy y

If lazy were not lazy, par would look strict in y which would defeat the whole purpose of par. Like seq, the argument of lazy can have an unboxed type.

Identity function.

id x = x

Magic function that tells the compiler not to inline the argument.

Sets a breakpoint in pure code

When evaluated, displays the names of variables visible from the callsite and starts a prompt where entering a variable will display its value. You may want to use this instead of breakpoint if there are value which should stay unevaluated or you are only interested in certain values. Only the current thread is blocked while the prompt is active. To resume execution, press enter with a blank prompt.

Transform a table by adding CAST to all columns. This is most useful for finalising a SELECT or RETURNING statement, guaranteed that the output matches what is encoded in each columns TypeInformation.

A default view function used when expression antiquotes are empty, or when pattern antiquotes omit a view pattern. See the documentation for rexPreprocessPat and rexPreprocessExp for more details. You can locally shadow this rexView with your own version, if you wish. One good option is readMay from the safe package: http://hackage.haskell.org/package/safe/docs/Safe.html#v:readMay. The type of this identity rexView is fully polymorphic so that it can be used with either String or ByteString.

This is the same as id. This can be an ergonomic way to pin down a polymorphic type in a function pipeline. For example:

-- Avoid this:
f . (\ x -> x :: Int) . g

-- Prefer this:
f . as @Int . g

Coerce a value from one type to another, bypassing the type-checker. There are several legitimate ways to use unsafeCoerce:

1. To coerce e.g. Int to HValue, put it in a list of HValue, and then later coerce it back to Int before using it.
2. To produce e.g. (a+b) :~: (b+a) from unsafeCoerce Refl. Here the two sides really are the same type -- so nothing unsafe is happening -- but GHC is not clever enough to see it.
3. In Data.Typeable we have

eqTypeRep :: forall k1 k2 (a :: k1) (b :: k2).
TypeRep a -> TypeRep b -> Maybe (a :~~: b)
eqTypeRep a b
| sameTypeRep a b = Just (unsafeCoerce HRefl)
| otherwise       = Nothing

Here again, the unsafeCoerce HRefl is safe, because the two types really are the same -- but the proof of that relies on the complex, trusted implementation of Typeable.

1. The "reflection trick", which takes advantage of the fact that in class C a where { op :: ty }, we can safely coerce between C a and ty (which have different kinds!) because it's really just a newtype. Note: there is no guarantee, at all that this behavior will be supported into perpetuity.

For safe zero-cost coercions you can instead use the coerce function from Data.Coerce.

Highly, terribly dangerous coercion from one representation type to another. Misuse of this function can invite the garbage collector to trounce upon your data and then laugh in your face. You don't want this function. Really.