- Glasgow-haskell-users

Why are arrays retainers?
by Akio Takano 31 Oct '12

31 Oct '12

Hi, Recently I was surprised to see that GHC's retainer profiler treated boxed arrays as retainer objects. Why are they considered retainers? I was using the +RTS -hr to figure out why there were a lot of objects of type T in the heap. However, the T objects happened to be in a HashMap (from the unordered-containers package), so the profiler pointed to the function that created the HashMap rather than the actual cause of the leak. This lead me to think that it might be useful if GHC would treat arrays as non-retainers. Also the behavior is not documented. The user's guide only mentions stacks and thunks as types of retainers, not mutable objects and boxed arrays. I'd be happy to submit a documentation patch. Regards, Takano Akio

2 2

Using GHC.TypeLits and singletons
by José Pedro Magalhães 29 Oct '12

29 Oct '12

Hi Iavor and Richard (CC ghc-users), If I recall correctly, Richard designed his singletons package in such a way that it would interact nicely with Iavor's type-level literals. Now I find myself in a situation where I need to use both type-level literals and singletons (basically because I'm reflecting at the value level both naturals, strings, and more complicated datatypes). But I see that the declarations of entities such as Sing, SingI, etc., are duplicated in the singletons package (seeing that they are already in GHC 7.6 within GHC.TypeLits). My question is: how can I use these two together? Thanks, Pedro

2 1

Understanding the core2core simplifier <-> occurence-analysis interaction
by Herbert Valerio Riedel 28 Oct '12

28 Oct '12

Hello GHC HQ, I've been trying to improve/fix a minor optimization sub-optimality w.r.t to the following code (code like that results from the generics-based NFData deriver[1]): data Foo = Foo1 | Foo2 | Foo3 !Int rnf1 :: Foo -> () rnf1 x = case x of Foo1 -> () Foo2 -> () Foo3 {} -> () which the current GHC 7.6.1 translates to the following core expression: NFDataTest2.rnf1 = \ x_aeG -> case x_aeG of _ { __DEFAULT -> GHC.Tuple.(); NFDataTest2.Foo3 ds_deT -> GHC.Tuple.() } ...whereas I'd have expected it to to compile it to a collapsed '__DEFAULT'-only case, i.e. NFDataTest2.rnf1 = \ x_aeG -> case x_aeG of _ { __DEFAULT -> GHC.Tuple.() } Now I've been hunting it down to the function SimplUtils.mkCase1 [2], which according to the source-code comments, is supposed to merge identical alternatives, i.e.: | 3. Merge identical alternatives. | If several alternatives are identical, merge them into | a single DEFAULT alternative. I've occasionally seen this | making a big difference: | | case e of =====> case e of | C _ -> f x D v -> ....v.... | D v -> ....v.... DEFAULT -> f x | DEFAULT -> f x ...and the 'mkCase1' function itself reads as follows: mkCase1 dflags scrut case_bndr alts_ty ((_con1,bndrs1,rhs1) : con_alts) | all isDeadBinder bndrs1 -- Remember the default , length filtered_alts < length con_alts -- alternative comes first -- Also Note [Dead binders] = do { tick (AltMerge case_bndr) ; mkCase2 dflags scrut case_bndr alts_ty alts' } where alts' = (DEFAULT, [], rhs1) : filtered_alts filtered_alts = filter keep con_alts keep (_con,bndrs,rhs) = not (all isDeadBinder bndrs && rhs `cheapEqExpr` rhs1) ...now the problem seems to be, that 'isDeadBinder' returns 'False'; so I hacked up 'mkCase1' and inserted a 'occurAnalyseExpr' on artificially constructed single-alternative 'Case' values before applying 'isDeadBinder', and then it would return 'True' and simplify the case expression as expected. So now my question is, why isn't the occurrence information available for the case-alternative's binders (the occInfo is set to 'NoOccInfo') at 'mkCase1'-time? When is occurence analysis performed relative to the simplifier? [1]: http://hackage.haskell.org/package/deepseq-generics [2]: http://www.haskell.org/ghc/docs/7.6.1/html/libraries/ghc-7.6.1/src/SimplUti… cheers, hvr --

1 1

GHC on OpenIndiana
by asyropoulos＠aol.com 28 Oct '12

28 Oct '12

Dear Developers, I am trying to compile the GHC on OpenIndiana (essentially Solaris 11). I follow the steps in http://www.haskell.org/ghc/docs/6.4.1/html/building/sec-porting-ghc.html#se… and here is what I get: $ ./distrib/hc-build --prefix=/opt/gnu/ghcb --enable-hc-boot *** Building compiler... checking for gfind... /usr/bin/gfind checking for sort... /opt/gnu/bin/sort checking for ghc... no checking build system type... i386-pc-solaris2.11 checking host system type... i386-pc-solaris2.11 checking target system type... i386-pc-solaris2.11 HOST: i386-pc-solaris2.11 Can't work out build platform Not e that configure.ac contains a section on Solaris: SOLARIS_BROKEN_SHLD=NO case $host in i386-*-solaris2) # here we go with the test MINOR=`uname -r|cut -d '.' -f 2-` if test "$MINOR" -lt "11"; then SOLARIS_BROKEN_SHLD=YES fi ;; esac For whatever the reason I "need to update configure.in to recognise the new architecture, and re-generate configure with autoreconf" but I have no idea what exactly to add. There is no template inside to help me. Could you please let me know what should I do to proceed? Thank you in advance for your help/suggestions. A.S. -- Apostolos Syropoulos Xanthi, Greece

3 2

RULES for ByteString are not fired
by Kazu Yamamoto 28 Oct '12

28 Oct '12

Hello, I seems to us (my friends and me) that term rewriting rules for ByteString are not fired in recent GHCs. 6.12.3 OK 7.0.4 NG 7.4.1 NG 7.6.1RC1 NG For example, with the example from this ticket http://hackage.haskell.org/trac/ghc/ticket/3703 results in as follows: % ghc -O -ddump-simpl-stats --make breakOn.hs 14 RuleFired 4 Class op showsPrec 2 Class op show 2 eqChar#->case 2 unpack 2 unpack-list 1 Class op == 1 Class op >> There is no ByteString rules. Is this a bug or intention? --Kazu {-# LANGUAGE OverloadedStrings #-} import qualified Data.ByteString.Char8 as B main :: IO () main = do let string1 = B.pack "This is a string" string2 = B.pack "This is another string" print (breakOn ' ' string1) print (breakOn ' ' string2) breakOn :: Char -> B.ByteString -> (B.ByteString, B.ByteString) breakOn c = B.break (c==)

3 2

ghc: panic! (the 'impossible' happened)
by José Romildo Malaquias 28 Oct '12

28 Oct '12

Hello. Today I wrote a small program to experiment with the Applicative class. The program is supposed to use an "applicative reader", similar to a "monad reader", to evaluate arithmetic expressions. But when compiling the program with ghc-7.6.1, I get the following message: $ ghc --make applicative-eval [1 of 1] Compiling Main ( applicative-eval.hs, applicative-eval.o ) ghc: panic! (the 'impossible' happened) (GHC version 7.6.1 for x86_64-unknown-linux): expectJust cpeBody:collect_args Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug If the line eval (Let s a b) = \m -> eval b ((s,eval a m):m) is commented out, the program compiles without problems. Is this a known issue with the compiler? The source code is attached. Romildo

3 3

Re: [Haskell-cafe] Problems translating Conor McBride's talk into Haskell + DataKind + KindPoly
by José Pedro Magalhães 26 Oct '12

26 Oct '12

Hi, Please use GHC 7.6 for experimenting with PolyKinds/DataKinds; the implementation in 7.4 was not fully complete. Your code compiles fine in 7.6. Cheers, Pedro On Fri, Oct 26, 2012 at 3:10 AM, Ahn, Ki Yung <kyagrd(a)gmail.com> wrote: > Promotion works for user defined lists such as > > data List a = Nil | Cons a (List a) > > And, if I use (List Bool) instead of [Bool] everything works out. > It's only the Haskell list type constructor [] is being a problem. > > In the "Giving Haskell a promotion" paper, it says that Haskell lists are > "natively promoted". I believe this means that it is treated specially > somehow. I don't know how it is implemented but what GHC 7.4.1 does > specially for Haskell lists has some problems. So, it's clearly not a > limitation of DataKind and PolyKind extension, but that special routine for > [] is the issue. > > I might have to write bug report. > > > On 2012년 10월 25일 18:07, Ahn, Ki Yung wrote: > >> Most part of Conor's talk at ICFP, until just before the last stage >> where he heavily uses true value dependency for compiler correctness all >> the code seemed to be able to translate into Haskell with the new hot >> DataKinds and PolyKinds extension. >> >> I tried it in GHC 7.4.1 and it was possible to do it, but I got stuck >> and I had to make the generic list structure mono-kinded with kind >> signatures rather not use the PolyKinds extension. >> >> I wonder if this is just a but of GHC 7.4.1's implementation of >> PolyKinds, or a limitation of the DataKind design. >> >> I attached a literate Haskell script with this message that illustrates >> this problem. >> >> Thanks in advance for any comments including whether it runs in later >> versions or still has problems, and discussions about the DataKinds and >> PolyKinds extension. >> >> Ki Yung >> >> >> ______________________________**_________________ >> Haskell-Cafe mailing list >> Haskell-Cafe(a)haskell.org >> http://www.haskell.org/**mailman/listinfo/haskell-cafe<http://www.haskell.org/mailman/listinfo/haskell-cafe> >> > > > > ______________________________**_________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://www.haskell.org/**mailman/listinfo/haskell-cafe<http://www.haskell.org/mailman/listinfo/haskell-cafe> >

1 0

Proposal: EPHEMERAL pragma
by José Pedro Magalhães 25 Oct '12

25 Oct '12

Hi all, Following up on a chat with Simon Peyton Jones at ICFP, I would like to discuss the possible introduction of a EPHEMERAL pragma. For example: {-# EPHEMERAL Rep #-} > data Rep = ... > This pragma would indicate that the programmer intends the Rep datatype not to be present in the final generated core code. Its proposed semantics are the following: 1. Make the compiler very keen to inline any functions that produce or consume Rep. 2. If Rep is exported, make all functions that operate on Rep INLINABLE (that is, make their code available for inlining in other modules). 3. Emit a warning if the generated core code still contains uses of Rep. My main use case for such a pragma is in the generic representation of datatypes in GHC.Generics. It's clear that we don't want sums and products lying around in user code, and in most cases we can get rid of them by inlining aggressively. Hopefully such a pragma can simplify or entirely replace the use of INLINE/INLINABLE pragmas in some cases. However, I'm not sure how well this can work in practice. Regarding (3), for instance, it's clear that functions that operate on Rep will be around in the final core code; perhaps only functions which do not directly produce or consume Rep, yet end up having values of Rep within them, should trigger a warning. (1) is hard to do well, in general. In particular when there are rewriting rules involving values of Rep, or functions that produce/consume Rep, the order in which they are inlined might affect the elimination of Rep values. In any case, I thought I'd share this with this list, in the hope to get feedback regarding how to improve the inliner (and the feedback programmers get regarding inlining). Cheers, Pedro

8 8

GHC compiling shared library linking problem
by Richard Zetterberg 22 Oct '12

22 Oct '12

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello This is the first time I'm mailing to this list, so I hope I have come to the right place. The problem I have is that I get a linker error when compiling a shared library with GHC. This problem occurred after I updated GHC from 7.0.3 to 7.4.1. Here is the error itself: /usr/bin/ld: ../src/Shared.so relocation R_X86_64_32S against `ghczmprim_GHCziTypes_ZC_con_info` can not be used when making a shared object; recompile with -fPIC ../src/Shared.so: could not read symbols: Bad value collect2: error: ld returned 1 exit status Here is the ghc command: ghc -O2 --make -no-hs-main -optl '-shared' -optc '-DMODULE=Shared' - - -o ../bin/pet_assembler_core.so Shared ../src/shared/module_init.c - - -i../src/; Shared.hs is the file where I specify the interface for the library, it only has one function: 1 {-# LANGUAGE ForeignFunctionInterface #-} 2 3 module Shared where 4 5 import qualified Data.ByteString as BS 6 import Foreign.Ptr (Ptr) 7 import Foreign.Storable (poke) 8 import Foreign.Marshal.Utils (copyBytes) 9 import Foreign.Marshal.Alloc (mallocBytes) 10 import Foreign.C.Types (CSize, CChar) 11 import Foreign.C.String 12 import Data.ByteString.Unsafe (unsafeUseAsCStringLen) 13 import Assembly.Data 14 import qualified Assembly as ASM 15 16 type PPString = Ptr (Ptr CChar) 17 type PSize = Ptr CSize 18 19 foreign export ccall assemble :: PPString -> PSize -> CString -> IO Int And the module_init.c contains initialization of the module: 1 #define CAT(a,b) XCAT(a,b) 2 #define XCAT(a,b) a ## b 3 #define STR(a) XSTR(a) 4 #define XSTR(a) #a 5 6 #include <HsFFI.h> 7 8 extern void CAT(__stginit_, MODULE)(void); 9 10 static void library_init(void) __attribute__((constructor)); 11 static void library_init(void) 12 { 13 static char *argv[] = { STR(MODULE) ".so", 0 }, **argv_ = argv; 14 static int argc = 1; 15 16 hs_init(&argc, &argv_); 17 hs_add_root(CAT(__stginit_, MODULE)); 18 } 19 20 static void library_exit(void) __attribute__((destructor)); 21 static void library_exit(void) 22 { 23 hs_exit(); 24 } Information about the system: Linux 2.6.32-5-amd64 Debian 6.0.6 GHC 7.4.1 GCC 4.7.2 GNU ld 2.22 So the question is, what could it be? Have I missed something? Or should I report this as a bug? Best regards Richard Zetterberg -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iQIcBAEBAgAGBQJQfA6/AAoJEP99n2Mvs+maKp4P/iznMCLd73Os0tOarCHcyiK4 b96Zi1ibD5jqiojAWseoX3xCj4uNKIGy20GzDKRS5gZi3rXkw+wuCyLfj/RetrbN 8sy3RNVpbNulwRn/0HnFDOINpAOlO/y+6l45YcfhTSJGRCR0Hv7yhhlHbcyezZ+G i4UORXygc2TnCVL1Vc0RdmmPOAehfmla1oo1bwmmQ6l6hhdrHJpo0jVukN+Dy+qv enGF4Z9IMVjtgZizmEHmFA9UbMpKDDCXHKTsCSliSKErx4ebz0VeEkCCXWXE9c5M 0sUkAmDkiV8+CJ+RPJBMjIDihuothQ4Hpt2ZWBXo6I4D7J9MkkW8Qe9kmwvzLQQO d7+w2qsHkI9x3bSnH6D3Co+crgqUnHf2OGDI8Hhbc2Ra82wcobCxHyxNWWAa8P07 q3/cu9xNDceTRnJ0tx9R2e9qByp5+eOAhtabNcX3yTsWWKSD2P0FNC2sjxMH/Psz mWIDAiFfOGrKRAilm3CxokeX5k+tPMP+piU3b2WNPEJHaS/Hgl9Xl4eHi/DRnzJ7 9Fu09ynoB3yllPyIzLijXdOrwaTt7qWwxt48D1TwX+hl7CRxwOCFJKXyeZoRiSTc D+Lbts5ST5skqnRHiQNxdrCODCvGoLhUJTDHEyVm3b9fFstkpR7tQc3nVywJ9DFH p9Sh9UdEAc9a1URkCXS4 =ZU3J -----END PGP SIGNATURE-----

3 4

divRem by `-' performance
by Serge D. Mechveliani 18 Oct '12

18 Oct '12

People, consider the following contrived program for division with remainder: ---------------------------------------------------------------- qRem :: Int -> Int -> (Int, Int) qRem m n = if m < 0 || n <= 0 then error "\nwrong arguments in qRem.\n" else qRem' 0 m where qRem' q r = if r < n then (q, r) else qRem' (succ q) (r - n) main = putStr $ shows (qRem n 5) "\n" where e = 25 n = 2^e ---------------------------------------------------------------- Compilation in ghc-7.4.1 : ghc --make -O -rtsopts Main Rinning: time ./Main +RTS -K.. -M.. -RTS For e = 25, it takes the minimum of -K80m -M280m (on my Linux Debian machine). Is not this memory eagerness strange? Regards, Sergei

3 7