January 2007 - Glasgow-haskell-users

partially applied type synonyms
by Arie Peterson 05 Mar '12

05 Mar '12

Dear list, Is there a good reason that partially applied type synonyms cannot be made instances of classes? - A simple example would be making the identity type 'Id' ("type Id x = x") instance of 'Monad'. This would eliminate the need for some silly occurrences of 'runIdentity', and perhaps narrow the gap between monads and monad transformers. - The reason I complain about this now is a more involved example, where introducing a newtype to work around the restriction is not an option. Well, not as far as I can see now, anyway. Partially applied type synonyms are, in a sense, the anonymous functions at the type level, and one might argue that they deserve the same 'first-class member status' as the lambda at the value level. Kind regards, Arie Peterson

3 2

ghc: out of memory error while compiling huge "let"
by David Morse 06 Feb '07

06 Feb '07

I have a machine-generated source-code file that brings my computer to its knees with ghc-6.6. After an hour or so of rummaging around, ghc dies with: "ghc-6.6: out of memory (requested 1048576 bytes)". The linux machine has 1gb RAM and 2gb swap, and I don't have access to a better one. The file is of the form ------------------------------------------- module foo (a,b) where (a,b) = let ...10,300 bindings... ; in ([a1,a2,a3...a300],[b1,b2,b3...b10000]) -------------------------------------------- Is there some simple syntactic refactoring I can do to make this work? E.g. busting the local bindings out of the "let" and into to the global level? The bindings are intertwined, but I could (with some effort) reorder them so that b5000 would only reference b5001...b10000 and never b1...b4999.

5 6

Problems building GHC
by Rodrigo Geraldo 31 Jan '07

31 Jan '07

Hi! I start to "hack" GHC, and, I 've tried to build it, but the build return this error message : ./compiler/stage1/ghc-inplace -o stage2/ghc -H64m -Onot -fasm -package ghc -Ist age2 -cpp -fglasgow-exts -fno-generics -Rghc-timing -I. -IcodeGen -InativeGen -I parser -Rghc-timing -Onot -fasm -DGHCI -DBREAKPOINT -threaded stage2/main /Main.o stage2/main/Main.o(.text+0x233c):ghc1888_0.hc: undefined reference to `ghczm6zi6 _DriverPhases_showsPrec1_closure' stage2/main/Main.o(.text+0x2567):ghc1888_0.hc: undefined reference to `ghczm6zi6 _DriverPhases_showsPrec1_info' stage2/main/Main.o(.text+0x25c2):ghc1888_0.hc: undefined reference to `ghczm6zi6 _DriverPhases_showsPrec1_info' stage2/main/Main.o(.text+0x3978):ghc1888_0.hc: undefined reference to `ghczm6zi6 _DriverPhases_haskellishzusrczusuffixes_closure' stage2/main/Main.o(.text+0x3c57):ghc1888_0.hc: undefined reference to `ghczm6zi6 _DriverPhases_haskellishzusrczusuffixes_closure' stage2/main/Main.o(.text+0x454e):ghc1888_0.hc: undefined reference to `ghczm6zi6 _GHC_zdwsetSessionDynFlags_closure' stage2/main/Main.o(.text+0x4552):ghc1888_0.hc: undefined reference to `ghczm6zi6 _GHC_zdwload_closure' stage2/main/Main.o(.text+0x4566):ghc1888_0.hc: undefined reference to `ghczm6zi6 _DriverPipeline_zdwcompileFile_closure' stage2/main/Main.o(.text+0x456a):ghc1888_0.hc: undefined reference to `ghczm6zi6 _DriverMkDepend_zdwdoMkDependHS_closure' stage2/main/Main.o(.text+0x4572):ghc1888_0.hc: undefined reference to `ghczm6zi6 _InteractiveUI_zdwinteractiveUI_closure' stage2/main/Main.o(.text+0x457a):ghc1888_0.hc: undefined reference to `ghczm6zi6 _Packages_zdwdumpPackages_closure' stage2/main/Main.o(.text+0x5b4e):ghc1888_0.hc: undefined reference to `ghczm6zi6 _DriverMkDepend_zdwdoMkDependHS_info' stage2/main/Main.o(.text+0x5bb8):ghc1888_0.hc: undefined reference to `ghczm6zi6 _InteractiveUI_zdwinteractiveUI_info' stage2/main/Main.o(.text+0x5bef):ghc1888_0.hc: undefined reference to `ghczm6zi6 _InteractiveUI_zdwinteractiveUI_info' stage2/main/Main.o(.text+0x66ce):ghc1888_0.hc: undefined reference to `ghczm6zi6 _Packages_zdwdumpPackages_info' stage2/main/Main.o(.text+0x5760):ghc1888_0.hc: undefined reference to `ghczm6zi6 _DriverPipeline_zdwcompileFile_info' stage2/main/Main.o(.text+0x5890):ghc1888_0.hc: undefined reference to `ghczm6zi6 _GHC_zdwload_info' stage2/main/Main.o(.text+0x58c4):ghc1888_0.hc: undefined reference to `ghczm6zi6 _GHC_zdwsetTargets_info' stage2/main/Main.o(.text+0x689b):ghc1888_0.hc: undefined reference to `ghczm6zi6 _GHC_zdwsetSessionDynFlags_info' collect2: ld returned 1 exit status <<ghc: 9924096 bytes, 3 GCs, 89824/89824 avg/max bytes residency (1 samples), 62 M in use, 0.02 INIT (0.00 elapsed), 0.03 MUT ( 17.44 elapsed), 0.00 GC (0.00 elap sed) :ghc>> make[3]: *** [stage2/ghc] Error 1 make[3]: Leaving directory `/c/ghc-build/ghc-6.6/compiler' make[2]: *** [stage2/ghc] Error 2 make[2]: Leaving directory `/c/ghc-build/ghc-6.6/compiler' make[1]: *** [stage2] Error 2 make[1]: Leaving directory `/c/ghc-build/ghc-6.6' make: *** [bootstrap2] Error 2 I've tried to build GHC using mSYS and MinGW under MS windows xp... Does anyone have any idea of how can I solve this problem? Thanks a lot! Rodrigo Ribeiro

1 0

(no subject)
by TFP 2007 31 Jan '07

31 Jan '07

Dear Colleagues, Apologies in advance for the "p.m." ommission. This is a kind reminder that the deadline for extended abstract submissions to TFP 2007 is tomorrow, Feb. 1 at 11:59 p.m. EST. We are also pleased to announce that the TFP 2007 invited speaker is John McCarthy, Stanford University. For further details, please visit our website at: http://cs.shu.edu/tfp2007/ . The TFP 2007 program committee looks forward to receiving your submissions! Best wishes, Marco ************************************************************************************ Dr. Marco T. Morazan TFP 2007 Program Committee Chair http://cs.shu.edu/tfp2007/

1 0

TFP 2007 Submission Deadline is Tomorrow
by TFP 2007 31 Jan '07

31 Jan '07

Dear Colleagues, This is a kind reminder that the deadline for extended abstract submissions to TFP 2007 is tomorrow, Feb. 1 at 11:59 EST. We are also pleased to announce that the TFP 2007 invited speaker is John McCarthy, Stanford University. For further details, please visit our website at: http://cs.shu.edu/tfp2007/ . The TFP 2007 program committee looks forward to receiving your submissions! Best wishes, Marco ************************************************************************************ Dr. Marco T. Morazan TFP 2007 Program Committee Chair http://cs.shu.edu/tfp2007/

1 0

hrm...
by John Meacham 29 Jan '07

29 Jan '07

so I have this simple bit of code, which should be fast but seems to be being compiled to something very slow. > import Data.Word > import Data.Bits > > fhb :: Word -> Word > fhb w = b1 .|. b2 where > b2 = if 0xFFFF0000 .&. w /= 0 then 0x2 else 0 > b1 = if 0xFF00FF00 .&. w /= 0 then 0x1 else 0 what it compiles to is something involving Integers, lots of coercions and other nasty stuff when it should consist of a couple of primitive operations. John -- John Meacham - ⑆repetae.net⑆john⑈

5 5

HEAD ghci crash on ppc OS X
by David Kirkman 28 Jan '07

28 Jan '07

I just built ghc from HEAD on OS X (ppc), and get the following error when starting ghci: ---start [15:15:15][david@isengard]$ compiler/stage2/ghc-inplace --interactive ___ ___ _ / _ \ /\ /\/ __(_) / /_\// /_/ / / | | GHC Interactive, version 6.7, for Haskell 98. / /_\\/ __ / /___| | http://www.haskell.org/ghc/ \____/\/ /_/\____/|_| Type :? for help. ghc-6.7(9972,0xa000ed88) malloc: *** error for object 0x3807ff8: pointer being reallocated was not allocated ghc-6.7(9972,0xa000ed88) malloc: *** set a breakpoint in szone_error to debug malloc: failed on request for 11359964 bytes; message: ocAllocateJumpIslands ---end despite the suggestion, a breakpoint in szone_error catches nothing. But a breakpoint in malloc_printf (both szone_error and malloc_printf in the OS, not ghc) gives the following backtrace for an rts compiled with the -g flag: --start Breakpoint 1, 0x9012bb94 in malloc_printf () (gdb) bt #0 0x9012bb94 in malloc_printf () #1 0x90018388 in szone_realloc () #2 0x90018098 in realloc () #3 0x00e6f5c4 in stgReallocBytes (p=0x901a4df4, n=11359964, msg=0xfd9704 "ocAllocateJumpIslands") at RtsUtils.c:209 #4 0x00e97cbc in ocAllocateJumpIslands (oc=0x2b005d0, count=372, first=14502) at Linker.c:1598 #5 0x00e98954 in loadObj (path=0x2e63268 "/Network/Sid/Users/david/ ghc-crap/ghc/libraries/base/HSbase.o") at Linker.c:3743 #6 0x005b660c in s1wt_info () #7 0x00e8a220 in schedule (initialCapability=0x901a4df4, task=0x2e63268) at Schedule.c:608 #8 0x00c60e18 in main (argc=-1877324300, argv=0x3807ff8) at Main.c:105 (gdb) --end The call to failing call to stgReallocBytes occurs at line 1598 of Linker.c, in the following context: --start Linker.c, lines 1597 --> 1602 oc->image -= misalignment; oc->image = stgReallocBytes( oc->image, misalignment + aligned + sizeof (ppcJumpIsland) * count, "ocAllocateJumpIslands" ); oc->image += misalignment; --end oc->image is allocated at line 1326 of Linker.c (listing below), and then never modified until misalignment is subtracted from it at line 1598. Both the comment in the code fragment below, and the actual code in the fragment above seem to indicate that oc->image should be offset by misalignment. --start Linker.c, lines 1315 --> 1327 # elif defined(darwin_HOST_OS) // In a Mach-O .o file, all sections can and will be misaligned // if the total size of the headers is not a multiple of the // desired alignment. This is fine for .o files that only serve // as input for the static linker, but it's not fine for us, // as SSE (used by gcc for floating point) and Altivec require // 16-byte alignment. // We calculate the correct alignment from the header before // reading the file, and then we misalign oc->image on purpose so // that the actual sections end up aligned again. oc->misalignment = machoGetMisalignment(f); oc->image = stgMallocBytes(oc->fileSize + oc->misalignment, "loadObj(image)"); # else ---end The comment above seems to be begging for a oc->image += oc->misalignment; statement right after the call to stgMallocBytes. But I'm assuming it must normally be done someplace else -- I just can't figure out where. Anyway, I've verified that os->image is still pointing to the value returned from stgMallocBytes when misalignment (non-zero) is subtracted from it just before the call to stgReallocBytes. So in my build at least, the execution path is not hitting whatever part of the code that should be applying the misalignment offset to oc->image. Let me know if there is any more information I can give. -david k.

3 4

ANN: regex-tdfa 0.56
by Chris Kuklewicz 27 Jan '07

27 Jan '07

Greetings, My new regular expression backend "regex-tdfa" is passing all the tests I have been throwing at it, so it is time to share the good news. First up: Where is it? Version 0.56 is in my "stable" location at > darcs get --partial darcs.haskell.org:/home/darcs/packages/regex-tdfa The version that will get updated and broken more often is "unstable" at > darcs get --partial darcs.haskell.org:/home/darcs/packages/regex-unstable/regex-tdfa It needs a slightly updated regex-base package (version >= 0.80) at > darcs get --partial darcs.haskell.org:/home/darcs/packages/regex-unstable/regex-base It has only been tested (on Max OS X) with GHC 6.6 and depends on base >= 2.0 for Data.ByteString, Data.ByteString.Lazy, and Data.Sequence. ** What does regex-tdfa do? It runs POSIX regular expression searches correctly. No other regular expression backend for Haskell does this correctly. The regular expression can be chosen to be from a String, ByteString, ByteString.Lazy, or (Data.Seq Char). Independent of that choice the searched text can also be any of those types. ** Properties and benefits of regex-tdfa: It follows a known standard: POSIX. (If you find that it disagrees with the standard then I will fix it.) It is written in Haskell, so there is no C library to compile and install. Though it is currently only written for GHC 6.6, it could be ported to any other compiler with only minor changes. (I expect that if you drop the polymorphic MPTC interface of regex-base it could be made Haskell98). It works with Unicode since it can be used on [Char] (and it works if there are '\NUL' characters around). It is lazy in the regular expression: it only builds the DFA if you use it, and only builds the state it needs, which are memoized in a lazy Trie. It is lazy in the searched text, and the pure function that searches the text only evaluates the text until the next match is done and does not hold onto the initial text. Thus you could efficiently search a [Char] up to the size of the Position type, which is an Int for now. It is free, the regex-tdfa library is under a BSD-3 license. ** Does it work? Yes. The regex-posix backend that come with GHC does not run all the searches correctly: it is buggy (example at end of announcement). And the regex-posix backend is also impossibly slow -- the slowest backend by far -- orders of magnitude slower. The regex-tre backend that wraps the TRE library has exposed this very fast library to the harsh gaze of QuickCheck. The lesson from QuickCheck is to never use regex-tre because the TRE library (version 0.7.4) is buggy. For regex-tdfa backend I took/stole ideas from Ville Laurikari's Master thesis which describes the algorithm that TRE uses. And I made a pure Haskell implementation that now passes all the tests at http://www.research.att.com/~gsf/testregex/testregex.html and follows the notes at http://www.research.att.com/~gsf/testregex/re-interpretation.html and passes those tests as well. And it "passes" QuickCheck tests which actually just compare the answers that regex-posix, regex-tre, and regex-tdfa since I do not have a bug free reference implementation to compare against. ** Why the name TDFA? Tagged Deterministic Finite Automata. The Tagged part is from Ville Laurikari's thesis work. ** Speed: If you do not care only about the match as a whole and not about subexpression matching then you can set the captureGroups ExecOption to False: makeMyRegex = makeRegex defaultCompOpt myExecOpt where myExecOpt = defaultExecOpt { captureGroups = False } And redefine (=~) and (=~~) to use makeMyRegex instead of makeRegex: (=~) :: (RegexMaker Regex CompOption ExecOption source,RegexContext Regex source1 target) => source1 -> source -> target (=~) s r = let re = makeMyRegex r :: Regex in match re s (=~~) :: (RegexMaker Regex CompOption ExecOption source,RegexContext Regex source1 target,Monad m)=> source1 -> source -> m target (=~~) s r = let re = makeMyRegex r :: Regex in match re s The benefit to this is speed, as it then proceeds to run all matches of "b(..?c)?d" against a large test file *faster* than the the TRE C library backend. My compliments to those who worked on ghc and -O2. It even runs nearly as fast as regex-dfa in this mode. Thus regex-dfa is (mostly) obsolete. If you use the default and capture the subgroups then the speed is reduced by a factor of about 4. This is because of the very simple data structures that keep track of the run time state. I intend to improve this aspect of the design now that I have a working algorithm. I have not benchmarked the speed of compiling the regular expression from the String. This compiling is done with very lazy data structures, so the DFA size is really only as big as you actually explore while running the match. ** Examples of bugs in regex-posix and regex-tre: An example for regex-posix: > *Main> "ab" Posix.=~ "((a)|(b)){2,}" :: MatchArray > array (0,3) [(0,(0,2)),(1,(1,1)),(2,(0,1)),(3,(1,1)) The array holds (group #, (match offset, match length)) The 0th group is the whole match "ab". The 2nd group is (a) and it matched the first "a" and the third group is (b) and matched the "b". But the second group is a child of the first group ((a)|(b)) which matched "b". The standard requires that captured groups are nested inside their parents, and here "a" is not not nested inside "b". So the regex-posix C backend that comes with GHC is buggy. The correct answer is, where the second group matched nothing: > *Main> "ab" TDFA.=~ "((a)|(b)){2,}" :: MatchArray > array (0,3) [(0,(0,2)),(1,(1,1)),(2,(-1,0)),(3,(1,1))] An example for regex-tre: "yyyyyy" TRE.=~ "(yyy|(x?)){2,4}" array (0,2) [(0,("yyyyyy",(0,6))),(1,("yyy",(3,3))),(2,("yyy",(3,3)))],"") Here TRE reports that the second group (x?) which should only match "" or "x" somehow matched "yyy". This is even more wrong than the regex-posix bug above. The correct answer, where the second group does not match: array (0,2) [(0,("yyyyyy",(0,6))),(1,("yyy",(3,3))),(2,("",(-1,0)))],"") -- Chris Kuklewicz

1 0

RE: [Haskell-cafe] proposal: HaBench, a Haskell Benchmark Suite
by Simon Peyton-Jones 26 Jan '07

26 Jan '07

| Following up and the threads on haskell and haskell-cafe, I'd like to | gather ideas, comments and suggestions for a standarized Haskell | Benchmark Suite. Great idea. Maybe this can subsume nofib. I recommend reading the nofib paper though: http://citeseer.ist.psu.edu/partain93nofib.html Simon

1 0

ByteArr# - nullByteArr# anyone?
by John Meacham 26 Jan '07

26 Jan '07

I would like to create a datatype that contains some memory managed by the GHC runtime, the natural fit is ByteArr#, however, in the common case, the ByteArr# won't actually have anything in it. would it be possible to have a single constant 'nullByteArr#'? I can't define a top level value of type ByteArr# and creating these values is in very performance critical code so I am not quite sure what to do. It would also be nice if byteArrContents# returned 'nullAddr#' for such byte arrays, but it is not a strict requirement. John -- John Meacham - ⑆repetae.net⑆john⑈

2 2