From 93297f092a1d99f97e43d0cd8a666668c1af2dda Mon Sep 17 00:00:00 2001 From: simonmar Date: Fri, 28 Nov 2003 10:55:59 +0000 Subject: [PATCH] [project @ 2003-11-28 10:55:59 by simonmar] Wibbles to the UNPACK docs. --- ghc/docs/users_guide/glasgow_exts.sgml | 17 +++++++++++------ 1 file changed, 11 insertions(+), 6 deletions(-) diff --git a/ghc/docs/users_guide/glasgow_exts.sgml b/ghc/docs/users_guide/glasgow_exts.sgml index b51278b..2a7f379 100644 --- a/ghc/docs/users_guide/glasgow_exts.sgml +++ b/ghc/docs/users_guide/glasgow_exts.sgml @@ -4250,12 +4250,12 @@ of the pragma. UNPACK pragma - UNPACK + UNPACK - There is another use for the UNPACK - pragma: to indicate that the compiler should unpack the contents - of a constructor field into the constructor itself, removing a - level of indirection. For example: + The UNPACK indicates to the compiler + that it should unpack the contents of a constructor field into + the constructor itself, removing a level of indirection. For + example: data T = T {-# UNPACK #-} !Float @@ -4300,7 +4300,12 @@ data S = S {-# UNPACK #-} !Int {-# UNPACK #-} !Int will store two unboxed Int#s - directly in the T constructor. + directly in the T constructor. The + unpacker can see through newtypes, too. + + If a field cannot be unpacked, you will not get a warning, + so it might be an idea to check the generated code with + . See also the flag, which essentially has the effect of adding -- 1.7.10.4