Haskell98 specifies that signed integers (type Int) must contain at least 30 bits. GHC always implements Int using the primitive type Int#, whose size equals the MachDeps.h constant WORD_SIZE_IN_BITS. This is normally set based on the config.h parameter SIZEOF_HSWORD, i.e., 32 bits on 32-bit machines, 64 bits on 64-bit machines. However, it can also be explicitly set to a smaller number, e.g., 31 bits, to allow the possibility of using tag bits. Currently GHC itself has only 32-bit and 64-bit variants, but 30 or 31-bit code can be exported as an external core file for use in other back ends.

GHC also implements a primitive unsigned integer type Word# which always has the same number of bits as Int#.

In addition, GHC supports families of explicit-sized integers and words at 8, 16, 32, and 64 bits, with the usual arithmetic operations, comparisons, and a range of conversions. The 8-bit and 16-bit sizes are always represented as Int# and Word#, and the operations implemented in terms of the the primops on these types, with suitable range restrictions on the results (using the narrow$n$Int# and narrow$n$Word# families of primops. The 32-bit sizes are represented using Int# and Word# when WORD_SIZE_IN_BITS $geq$ 32; otherwise, these are represented using distinct primitive types Int32# and Word32#. These (when needed) have a complete set of corresponding operations; however, nearly all of these are implemented as external C functions rather than as primops. Exactly the same story applies to the 64-bit sizes. All of these details are hidden under the PrelInt and PrelWord modules, which use #if-defs to invoke the appropriate types and operators.

Word size also matters for the families of primops for indexing/reading/writing fixed-size quantities at offsets from an array base, address, or foreign pointer. Here, a slightly different approach is taken. The names of these primops are fixed, but their types vary according to the value of WORD_SIZE_IN_BITS. For example, if word size is at least 32 bits then an operator like indexInt32Array# has type ByteArr# -> Int# -> Int#; otherwise it has type ByteArr# -> Int# -> Int32#. This approach confines the necessary #if-defs to this file; no conditional compilation is needed in the files that expose these primops.

Finally, there are strongly deprecated primops for coercing between Addr#, the primitive type of machine addresses, and Int#. These are pretty bogus anyway, but will work on existing 32-bit and 64-bit GHC targets; they are completely bogus when tag bits are used in Int#, so are not available in this case.

Return non-zero if there is any possibility that the upper word of a signed integer multiply might contain useful information. Return zero only if you are completely sure that no overflow can occur. On a 32-bit platform, the recommmended implementation is to do a 32 x 32 -> 64 signed multiply, and subtract result[63:32] from (result[31] >>signed 31). If this is zero, meaning that the upper word is merely a sign extension of the lower one, no overflow can occur.

On a 64-bit platform it is not always possible to acquire the top 64 bits of the result. Therefore, a recommended implementation is to take the absolute value of both operands, and return 0 iff bits[63:31] of them are zero, since that means that their magnitudes fit within 31 bits, so the magnitude of the product must fit into 62 bits.

If in doubt, return non-zero, but do make an effort to create the correct answer for small args, since otherwise the performance of (*) :: Integer -> Integer -> Integer will be poor.

Operations on arbitrary-precision integers. These operations are implemented via the GMP package. An integer is represented as a pair consisting of an Int# representing the number of 'limbs' in use and the sign, and a ByteArr# containing the 'limbs' themselves. Such pairs are returned as unboxed pairs, but must be passed as separate components.

For .NET these operations are implemented by foreign imports, so the primops are omitted.

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 in User's Guide, Section 7.10.3, "INLINE and NOINLINE 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. That is, f must be let-bound in the current scope. If no inlining takes place, the inline function expands to the identity function in Phase zero; so its use imposes no overhead.

If the function is defined in another module, GHC only exposes its inlining in the interface file if the function is sufficiently small that it might be inlined by the automatic mechanism. There is currently no way to tell GHC to expose arbitrarily-large functions in the interface file. (This shortcoming is something that could be fixed, with some kind of pragma.)

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

The function unsafeCoerce# allows you to side-step the typechecker entirely. That is, it allows you to coerce any type into any other type. If you use this function, you had better get it right, otherwise segmentation faults await. It is generally used when you want to write a program that you know is well-typed, but where Haskell's type system is not expressive enough to prove that it is well typed.

The argument to unsafeCoerce# can have unboxed types, although extremely bad things will happen if you coerce a boxed type to an unboxed type.