From: simonpj@microsoft.com Date: Mon, 4 Dec 2006 01:31:16 +0000 (+0000) Subject: Add documentation for seq X-Git-Url: http://git.megacz.com/?p=ghc-hetmet.git;a=commitdiff_plain;h=b55fe864599e77f2ae2a3fbeec899ea7aeeac9f2 Add documentation for seq --- 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. + + +