- Haskell-Cafe - Haskell.org

Re: Haskell-Cafe Digest, Vol 39, Issue 6
by Chad Scherrer 06 Nov '06

06 Nov '06

Lemmih wrote: > Using 'seq' is generally a bad idea. It can worsen the performance if > not used carefully and GHCs strictness analyser is usually good > enough. Is GHC.Conc.pseq any better? Usually the whole point of making things more strict is to optimize performance for pieces you know will be evaluated anyway. It's frustrating if there's not a consistent way to do this that works well. Lately, I've been using lots of strictness annotations and bang patterns - are there non-obvious places this could slow things down? Would it be possible for the type system to distinguish at compile time whether something would need to be evaluated, and optimize away redundant `seq`s? Maybe this is what the strictness analyzer does already. Chad

4 4

Module visibility of data type constructors
by Slavomir Kaslev 05 Nov '06

05 Nov '06

Hello. I have a simple question for data type constructors visibility. Take a look: module Foo (Bar) where data Bar = Bar In ghc this allows me to use Bar, the type constructor, in another module, although it shouldn't be visible outside Foo. On the other hand, if I change Bar's definition as: data Bar = Baz Baz isn't visible outside Foo. Is this the correct behavior or is it bug in ghc? Cheers. -- Slavomir Kaslev

3 5

64bit code output is less optimized than 32bit in ghc?
by isto 05 Nov '06

05 Nov '06

Hi again, Still playing with the Mersenne Twister and here is the updated 64 bit version so that there are not so many constructor calls on next64 (together with updated compiling flags). I was wondering why different runs can have such different run times and the cause was found to be my system: also the C version running times can vary (usually 0.65 but sometimes 0.3). The 64 bit version took usually about 1.1 or 1.2 seconds while 32bit version required only 0.78 (against 0.65 with C for both 32 and 64 bit versions). Since the real work horse here is the next64 function, I took a look of Core. There seems to be an extra case-statement in 64bit version and this might explain the performance drop (about 6 or 7 lines below _DEFAULT text on both versions below). Relevant parts of the Core below, code attached. It is very possible that I'm missing something obvious here. So what is happening here? :) Thanks again for any comments! br, Isto -------------------------------------------- Core (32 and 64 nexts) Rec { Mersenne.$wnext64 :: Data.Array.IO.Internals.IOUArray GHC.Base.Int GHC.Word.Word64 -> GHC.Prim.Int# -> GHC.Prim.State# GHC.Prim.RealWorld -> (# GHC.Prim.State# GHC.Prim.RealWorld, (GHC.Word.Word64, GHC.Base.Int) #) [GlobalId] [Arity 3 Str: DmdType LLL] Mersenne.$wnext64 = \ (w_s2Zq :: Data.Array.IO.Internals.IOUArray GHC.Base.Int GHC.Word.Word64) (ww_s2Zt :: GHC.Prim.Int#) (w1_s2Zv :: GHC.Prim.State# GHC.Prim.RealWorld) -> case ww_s2Zt of ds_X2F1 { __DEFAULT -> case w_s2Zq of wild_a2Pp { Data.Array.Base.STUArray ds2_a2Pr ds3_a2Ps marr#_a2Pt -> case GHC.Prim.readWord64Array# @ GHC.Prim.RealWorld marr#_a2Pt ds_X2F1 w1_s2Zv of wild2_a2PA { (# s2#_a2PC, e#_a2PD #) -> (# s2#_a2PC, ((case lit_r34C of wild1_a2Ol { GHC.Word.W64# y#_a2On -> let { ww1_a2NY [Just L] :: GHC.Prim.Word# [Str: DmdType] ww1_a2NY = GHC.Prim.xor# e#_a2PD (GHC.Prim.and# (GHC.Prim.uncheckedShiftRL# e#_a2PD 29) __word 6148914691236517205) } in let { ww2_X2Q0 [Just L] :: GHC.Prim.Word# [Str: DmdType] ww2_X2Q0 = GHC.Prim.xor# ww1_a2NY (GHC.Prim.and# (GHC.Prim.uncheckedShiftL# ww1_a2NY 17) __word 8202884508482404352) } in let { ww3_X2QE [Just L] :: GHC.Prim.Word# [Str: DmdType] ww3_X2QE = GHC.Prim.xor# ww2_X2Q0 (GHC.Prim.and# (GHC.Prim.uncheckedShiftL# ww2_X2Q0 37) y#_a2On) } in GHC.Word.W64# (GHC.Prim.xor# ww3_X2QE (GHC.Prim.uncheckedShiftRL# ww3_X2QE 43)) }), (GHC.Base.I# (GHC.Prim.+# ds_X2F1 1))) #) } }; 312 -> case Mersenne.generateNumbers64 w_s2Zq w1_s2Zv of wild_a2DL { (# new_s_a2DN, a87_a2DO #) -> case Mersenne.$wnext64 w_s2Zq 0 new_s_a2DN of wild1_X2Fy { (# new_s1_X2FB, a871_X2FD #) -> case a871_X2FD of wild2_Xar { (w2_aU2, iN_aU3) -> (# new_s1_X2FB, wild2_Xar #) } } } } end Rec } Mersenne.next64 :: Data.Array.IO.Internals.IOUArray GHC.Base.Int GHC.Word.Word64 -> GHC.Base.Int -> GHC.IOBase.IO (GHC.Word.Word64, GHC.Base.Int) [GlobalId] [Arity 3 Worker Mersenne.$wnext64 Str: DmdType LU(L)L] Mersenne.next64 = __inline_me (\ (w_s2Zq :: Data.Array.IO.Internals.IOUArray GHC.Base.Int GHC.Word.Word64) (w1_s2Zr :: GHC.Base.Int) (w2_s2Zv :: GHC.Prim.State# GHC.Prim.RealWorld) -> case w1_s2Zr of w3_X30R { GHC.Base.I# ww_s2Zt -> Mersenne.$wnext64 w_s2Zq ww_s2Zt w2_s2Zv }) Rec { Mersenne.$wnext32 :: Data.Array.IO.Internals.IOUArray GHC.Base.Int GHC.Word.Word32 -> GHC.Prim.Int# -> GHC.Prim.State# GHC.Prim.RealWorld -> (# GHC.Prim.State# GHC.Prim.RealWorld, (GHC.Word.Word32, GHC.Base.Int) #) [GlobalId] [Arity 3 NoCafRefs Str: DmdType LLL] Mersenne.$wnext32 = \ (w_s2YJ :: Data.Array.IO.Internals.IOUArray GHC.Base.Int GHC.Word.Word32) (ww_s2YM :: GHC.Prim.Int#) (w1_s2YO :: GHC.Prim.State# GHC.Prim.RealWorld) -> case ww_s2YM of ds_X2CS { __DEFAULT -> case w_s2YJ of wild_a2Hd { Data.Array.Base.STUArray ds2_a2Hf ds3_a2Hj marr#_a2Hk -> case GHC.Prim.readWord32Array# @ GHC.Prim.RealWorld marr#_a2Hk ds_X2CS w1_s2YO of wild2_a2Hr { (# s2#_a2Ht, e#_a2Hu #) -> (# s2#_a2Ht, ((let { ww1_a2Fr [Just L] :: GHC.Prim.Word# [Str: DmdType] ww1_a2Fr = GHC.Prim.xor# e#_a2Hu (GHC.Prim.uncheckedShiftRL# e#_a2Hu 11) } in let { ww2_X2GX [Just L] :: GHC.Prim.Word# [Str: DmdType] ww2_X2GX = GHC.Prim.xor# ww1_a2Fr (GHC.Prim.and# (GHC.Prim.narrow32Word# (GHC.Prim.uncheckedShiftL# ww1_a2Fr 7)) __word 2636928640) } in let { ww3_X2Hp [Just L] :: GHC.Prim.Word# [Str: DmdType] ww3_X2Hp = GHC.Prim.xor# ww2_X2GX (GHC.Prim.and# (GHC.Prim.narrow32Word# (GHC.Prim.uncheckedShiftL# ww2_X2GX 15)) __word 4022730752) } in GHC.Word.W32# (GHC.Prim.xor# ww3_X2Hp (GHC.Prim.uncheckedShiftRL# ww3_X2Hp 18))), (GHC.Base.I# (GHC.Prim.+# ds_X2CS 1))) #) } }; 624 -> case Mersenne.generateNumbers32 w_s2YJ w1_s2YO of wild_a2DL { (# new_s_a2DN, a87_a2DO #) -> case Mersenne.$wnext32 w_s2YJ 0 new_s_a2DN of wild1_X2F2 { (# new_s1_X2F5, a871_X2F7 #) -> case a871_X2F7 of wild2_X80 { (w2_aSH, iN_aSI) -> (# new_s1_X2F5, wild2_X80 #) } } } } end Rec } Mersenne.next32 :: Data.Array.IO.Internals.IOUArray GHC.Base.Int GHC.Word.Word32 -> GHC.Base.Int -> GHC.IOBase.IO (GHC.Word.Word32, GHC.Base.Int) [GlobalId] [Arity 3 Worker Mersenne.$wnext32 NoCafRefs Str: DmdType LU(L)L] Mersenne.next32 = __inline_me (\ (w_s2YJ :: Data.Array.IO.Internals.IOUArray GHC.Base.Int GHC.Word.Word32) (w1_s2YK :: GHC.Base.Int) (w2_s2YO :: GHC.Prim.State# GHC.Prim.RealWorld) -> case w1_s2YK of w3_X2ZO { GHC.Base.I# ww_s2YM -> Mersenne.$wnext32 w_s2YJ ww_s2YM w2_s2YO })

1 0

Unicode strings
by Pupeno 05 Nov '06

05 Nov '06

Hello, I am trying to make a program that outputs some Unicode characters but the output doesn't match what I try to print. Attached is a little test program. It tries to print the arrows "←↑→↓" but instead it outputs "\220\221\222\223" (that is, character number 220, then 221, then 222). I've also tried writing the Unicode code points (although GHC 6.6 should deal just fine with Unicode source code) and I get the same result. In case anybody wants to try, this would be the string: "\8592\8593\8594\8595". I am also attaching the output file, you can see that the contents are not right. Any ideas what am I doing wrong here ? Thank you. -- Pupeno <pupeno(a)pupeno.com> (http://pupeno.com)

4 3

A restricted subset of CPP included in a revision of Haskell 98
by Brian Smith 05 Nov '06

05 Nov '06

Hi, I find it strange that right now almost every Haskell program directly or indirectly (through FPTOOLS) depends on CPP, yet there is no effort to replace CPP with something better or standardize its usage in Haskell. According to the following document, and my own limited experience in reading Haskell code, CPP is the most frequently used extension: http://hackage.haskell.org/trac/haskell-prime/wiki/HaskellExtensions I think that if we accepted that CPP was part of the language, we could then place some restrictions on its use to facilitate easier parsing. Here are some suggestions, off the top of my head: * #define can only be used for parameterless definitions * #define'd symbols are only visible to the preprocessor * #define can only give a symbol a value that is a valid preprocessor expression * #define can only appear above the module declaration * a preprocessor symbol, once defined, cannot be undefined or redefined * #include and #undef are prohibited * The preprocessor can only be used at the top level. In particular, a prepropcessor conditional, #error, #warn, #line would not be allowed within the export list or within a top-level binding. * A Haskell program must assume that any top-level symbol definitions are constant over the entire program. For example, a program must not depend on having one module compiled with one set of command-line preprocessor symbol bindings and another module defined with a different set of bindings. * preprocessor directives must obey Haskell's layout rules. For example, an #if cannot be indented more than the bindings it contains. The result would be: * Syntax can be fully checked without knowing the values of any preprocessor symbols. * Preprocessor syntax can be added easily to a Haskell parser's BNF description of Haskell. * No tool will need to support per-file/module preprocessor symbol bindings. Again, all this is just off the top of my head. I am curious about what problems these restrictions might cause, especially for existing programs. I know that GHC itself uses some features that would be prohibited here. But, GHC is really difficult for tools to handle even with these restrictions on its source code. For now, I am more interested in the libraries in FPTOOLS and users' programs. What libraries/programs cannot easily be reorganizated to meet these restrictions? I suspect "#define'd symbols are only visible to the preprocessor" would be the most troublesome one. Thanks, Brian

7 9

Re[2]: [Haskell] GHC inferred type different for pointed/point-free defs?
by Bulat Ziganshin 04 Nov '06

04 Nov '06

Hello Dan, Saturday, November 4, 2006, 3:49:13 AM, you wrote: > You might want to rename your (&&&) and (|||), though, since they clash > with those defined in Control.Arrow. > I found that by defining (???) then way I did, I could use > (Control.Arrow.|||) as-is for the second part. i just not use arrows because i don't understand them. my definitions of "&&&" and "|||" is like those in C/perl/ruby and most times i use them alone: debugging &&& debug_info, first_time ||| putStrLn "" in the far future, i will be glad to see && and || redefined in this way (or some like this; it should just provide ruby's look&feel plus extensibility). although for my own program this may be solved by just not importing Prelude. hmmm, i should think about it.. but && and || functions is not exactly the same as ?: operator (nor in C, nor in standard Haskell, nor in my implementation). with these operations condition is tested _twice_ and if second argument has "false" value, third one will be returned anyway: True && False || True => True True ? False : True => False btw, it may be extended slightly more by adding application version: a &&. f = a &&& (f a) example: str &&. ("debug info: "++) now such function named unlessNull that is not so neat -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

1 0

Re: [Haskell] GHC inferred type different for pointed/point-free defs?
by Neil Mitchell 03 Nov '06

03 Nov '06

Hi, You probably want to read up on: Monomorphism restriction (I don't think this applies here, but I'm never too sure!): http://www.haskell.org/hawiki/MonomorphismRestriction Defaulting: http://www.haskell.org/onlinereport/decls.html#sect4.3.4 I don't understand either to any great degree, but when points free starts changing things, its usually one of those two kicking in. And as a side note, haskell@ tends to be used more for announcements, and haskell-cafe@ is used more for asking questions etc. Thanks Neil On 11/3/06, Dan Weston <westondan(a)imageworks.com> wrote: > Help! One of two things is going on: > > 1) I don't understand what I'm doing > 2) GHC is inferring different types for pointed and > point-free function definition. > > I wanted to define Haskell equivalents to the C ternary operator. > Basically, predicate ??? doIfTrue ||| doIfFalse > > For some reason, though, in GHC 6.4 and 6.7, the types > inferred for abs1 and ab2 (defined below) are different: > > *Main> :t abs1 > abs1 :: (Num a, Ord a) => a -> a > > *Main> :t abs2 > abs2 :: Integer -> Integer > > How is abs2 less general just because I use point-free > notation instead of pointed notation? They should have the same > type, no? I'm stumped... > > > import Control.Arrow > > import Data.Either > > > > infix 1 ?, ??, ???, ???? > > > > (?) True = Left > > (?) False = Right > > > > (??) True = Left . fst > > (??) False = Right . snd > > > > p ??? q = (p &&& arr id) >>> uncurry (?) >>> q > > p ???? q = (p &&& arr id) >>> uncurry (??) >>> q > > > > abs1 x = (< 0) ??? negate ||| id $ x > > abs2 = (< 0) ??? negate ||| id > > > > checks :: [Bool] > > checks = > > [ > > (True ? 3 ) == (Left 3), > > (False ? 4 ) == (Right 4), > > (True ?? (3,4)) == (Left 3), > > (False ?? (3,4)) == (Right 4), > > (even ??? (`div` 2) ||| (+1).(*3) $ 3 ) == ( 10), > > (even ??? (`div` 2) ||| (+1).(*3) $ 4 ) == ( 2), > > (uncurry (==) ???? (+1) ||| (*3) $ (3,3)) == ( 4), > > (uncurry (==) ???? (+1) ||| (*3) $ (3,4)) == ( 12), > > (uncurry (==) ???? (+1) +++ (*3) $ (3,3)) == (Left 4), > > (uncurry (==) ???? (+1) +++ (*3) $ (3,4)) == (Right 12), > > (abs1 5 ) == ( 5), > > (abs1 (-5) ) == ( 5), > > (abs2 5 ) == ( 5), > > (abs2 (-5) ) == ( 5) > > ] > > > > main = print (and checks) > > _______________________________________________ > Haskell mailing list > Haskell(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell >

1 0

Finding Memory Leaks
by Matthew Bromberg 03 Nov '06

03 Nov '06

I have a rather complex Haskell program that performs an engineering simulation using a lot of large complex valued matrices. The imperative components of the simulation are written in C and interfaced into Haskell which handles the higher level logic. This has served me fairly well, and I've been pleased with both the development style and the performance of my code. However I've run into a fairly major issue with an unresolvable memory leak in the Haskell code. The memory leak is apparent since both private allocated bytes and page file bytes associated with the process increase linearly over time while the process is running. Eventually it causes the process to crash. I believe it's in the Haskell code because I have replaced malloc, free, realloc etc. in the C code with a memory leak detector and the C code appears to free all allocated resources. I also know that the memory leak is due to unmatched free's from a call to malloc from one of the windows XP system libraries. Unfortunately GHC's heap profiler does not reveal the memory leak. All my code is compiled using the -prof -auto flag and then run using +RTS -hc -RTS. The resulting plots do not show a linear increase in heap usage, although the Windows XP operating system does report such an increase. This leaves me in a difficult position in terms of finding the offending code. I am currently resorting to commenting out code line by line, but it's very tedious since I have to preserve the state functionality of the code to get it to run. Is there a way to compile Haskell into C using GHC and then forcing the C code to hook up to the memory leak detecting versions of malloc? I know that GHC can produce intermediary C code, but I have no idea how to access it and how to setup all the run time libraries etc, so that I can compile the C code separately. Any advice for me in this situation would be appreciated.

4 5

[Haskell-cafe]Prime Generator time limit exceeded
by alaiyeshi 03 Nov '06

03 Nov '06

Hi I'm new to Haskell. I found this site on the Haskell wiki https://www.spoj.pl. But I got some trouble on trying to solve the problem titled "Prime Generator" https://www.spoj.pl/problems/PRIME1. The online-judge system tells me "time limit excedded" Would you be so kind to tell me how to make it more faster? And any other suggestion is welcome. Thanks in advance. --------------------------------------Code begin------------------------------------------------------------ module Main where import IO import List main = do input_size<-getLine content<-get_contents (read input_size) mapM_ (\r-> do mapM_ (print) (primeGenerator (parse r)); putStrLn "") content get_contents n | n == 0 = return [] | otherwise = do content<-getLine rests<-get_contents (n-1) return ([content]++rests) primeGenerator [start,end] = [x | x<-[start..end], all (== 1) (map (gcd x) [2..(x-1)]), x/=1] parse s = unfoldr (\x-> case x of [] -> Nothing _ -> Just (head (reads x))) s -------------------------------Code ends-------------------------------------------------------------------------------- (BTW: I'm new to this mailling list also, forgive my rudeness if I am, and forgive my poor English)

5 11

Cost of seq (sorry about the old subject)
by Chad Scherrer 03 Nov '06

03 Nov '06

On 11/2/06, Bulat Ziganshin <bulat.ziganshin(a)gmail.com> wrote: > Hello Chad, > > Thursday, November 2, 2006, 8:49:17 PM, you [Chad] wrote: > > Would it be possible for the type system to distinguish at compile > > time whether something would need to be evaluated, and optimize away > > redundant `seq`s? Maybe this is what the strictness analyzer does > > already. > > afaik, seq cost is zero (except for evaluating expressions, of course) > So if x has already been evaluated, does x `seq` y evaluate just as quickly as y alone, or does it require extra cycles to make sure x has been evaluated? -- Chad Scherrer "Time flies like an arrow; fruit flies like a banana" -- Groucho Marx

2 1