From b55fe864599e77f2ae2a3fbeec899ea7aeeac9f2 Mon Sep 17 00:00:00 2001 From: "simonpj@microsoft.com" Date: Mon, 4 Dec 2006 01:31:16 +0000 Subject: [PATCH] Add documentation for seq --- docs/users_guide/glasgow_exts.xml | 28 ++++++++++++++++++++++++++++ 1 file changed, 28 insertions(+) diff --git a/docs/users_guide/glasgow_exts.xml b/docs/users_guide/glasgow_exts.xml index c370ce3..052c9c3 100644 --- a/docs/users_guide/glasgow_exts.xml +++ b/docs/users_guide/glasgow_exts.xml @@ -6130,6 +6130,22 @@ r) -> described in this section. All are exported by GHC.Exts. + The <literal>seq</literal> function + +The function seq is as described in the Haskell98 Report. + + seq :: a -> b -> b + +It evaluates its first argument to head normal form, and then returns its +second argument as the result. The reason that it is documented here is +that, despite seq's polymorphism, its +second argument can have an unboxed type, or +can be an unboxed tuple; for example (seq x 4#) +or (seq x (# p,q #)). This requires b +to be instantiated to an unboxed type, which is not usually allowed. + + + The <literal>inline</literal> function The inline function is somewhat experimental. @@ -6188,6 +6204,11 @@ 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 <literal>unsafeCoerce#</literal> function @@ -6203,7 +6224,14 @@ 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. + + + -- 1.7.10.4