February 2006 - Glasgow-haskell-users

newtype and rules
by John Meacham 09 Feb '06

09 Feb '06

I am curious if rules pragmas are applied before or after newtype desugaring? basically what I want to know is if I have a newtype of an Int say, and make a rule acting on the newtype, will it be applied to any Int as well? John -- John Meacham - ⑆repetae.net⑆john⑈

1 0

RE: instance inference
by Simon Peyton-Jones 09 Feb '06

09 Feb '06

Thank you Ross. I've committed your patch, and added documentation. Simon | -----Original Message----- | From: glasgow-haskell-users-bounces(a)haskell.org [mailto:glasgow-haskell-users- | bounces(a)haskell.org] On Behalf Of Ross Paterson | Sent: 06 February 2006 11:36 | To: Simon Peyton-Jones; glasgow-haskell-users(a)haskell.org | Subject: Re: instance inference | | A patch implementing a relaxed termination constraint is at | | http://www.soi.city.ac.uk/~ross/instance-termination.patch | | Here is the description: | | With -fglasgow-exts but not -fallow-undecidable-instances, GHC 6.4 | requires that instances be of the following form: | | (1) each assertion in the context must constrain distinct variables | mentioned in the head, and | | (2) at least one argument of the head must be a non-variable type. | | This patch replaces these rules with the requirement that each | assertion in the context satisfy | | (1) no variable has more occurrences in the assertion than in the | head, and | | (2) the assertion has fewer constructors and variables (taken together | and counting repetitions) than the head. | | This allows all instances permitted by the old rule, plus such | instances as | | instance C a | instance Show (s a) => Show (Sized s a) | instance (Eq a, Show b) => C2 a b | instance C2 Int a => C3 Bool [a] | instance C2 Int a => C3 [a] b | instance C4 a a => C4 [a] [a] | | but still ensures that under any substitution assertions in the context | will be smaller than the head, so context reduction must terminate. | | This is probably the best we can do if we consider each instance in | isolation. | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

1 0

Passing a matrix from C to Haskell
by Cyril Schmidt 08 Feb '06

08 Feb '06

I need to pass a big 2-dimensional array of doubles from a legacy C code to a Haskell module. Of this huge array, the Haskell code will actually use only a few elements (say, 10 out of 100x20 matrix). Unfortunately, the C code does not know which data are actually needed in the Haskell module. What would be a good way to pass the array to Haskell and, once the data are handed over, what is the fastest way to fetch these elements? I was thinking of something like passing the array as Ptr Int#, but how do I fetch the elements that I am interested in? Cheers, Cyril

6 9

Fwd: patch applied (ghc): make the smp way RTS-only, normal libraries now work with -smp
by Bulat Ziganshin 08 Feb '06

08 Feb '06

i think that this should be interesting for GHC users This is a forwarded message From: Simon Marlow <simonmar(a)microsoft.com> To: cvs-ghc(a)haskell.org Date: Wednesday, February 08, 2006, 5:40:19 PM Subject: patch applied (ghc): make the smp way RTS-only, normal libraries now work with -smp ===8<==============Original message text=============== Wed Feb 8 06:33:48 PST 2006 Simon Marlow <simonmar(a)microsoft.com> * make the smp way RTS-only, normal libraries now work with -smp We had to bite the bullet here and add an extra word to every thunk, to enable running ordinary libraries on SMP. Otherwise, we would have needed to ship an extra set of libraries with GHC 6.6 in addition to the two sets we already ship (normal + profiled), and all Cabal packages would have to be compiled for SMP too. We decided it best just to take the hit now, making SMP easily accessible to everyone in GHC 6.6. Incedentally, although this increases allocation by around 12% on average, the performance hit is around 5%, and much less if your inner loop doesn't use any laziness. M ./ghc/compiler/codeGen/CgForeignCall.hs -6 +5 M ./ghc/compiler/codeGen/CgHeapery.lhs -3 +1 M ./ghc/compiler/codeGen/CgPrimOp.hs -4 +1 M ./ghc/compiler/codeGen/ClosureInfo.lhs -24 +15 M ./ghc/compiler/codeGen/SMRep.lhs -3 +2 M ./ghc/compiler/ghci/ByteCodeAsm.lhs +2 M ./ghc/compiler/ghci/ByteCodeGen.lhs -11 +13 M ./ghc/compiler/ghci/ByteCodeInstr.lhs -1 +3 M ./ghc/compiler/ghci/ByteCodeItbls.lhs -3 +3 M ./ghc/compiler/main/Constants.lhs -2 +1 M ./ghc/compiler/main/StaticFlags.hs -7 +4 M ./ghc/includes/Bytecodes.h -22 +23 M ./ghc/includes/Closures.h -11 +10 M ./ghc/includes/Cmm.h -4 M ./ghc/includes/Constants.h -21 +4 M ./ghc/includes/Storage.h -2 +67 M ./ghc/includes/mkDerivedConstants.c -39 +6 M ./ghc/rts/Apply.cmm -1 +1 M ./ghc/rts/GC.c -6 +6 M ./ghc/rts/GCCompact.c -55 +1 M ./ghc/rts/Interpreter.c -21 +30 M ./ghc/rts/LdvProfile.c -89 +19 M ./ghc/rts/LdvProfile.h -1 +1 M ./ghc/rts/Linker.c +2 M ./ghc/rts/ProfHeap.c -3 +3 M ./ghc/rts/RetainerProfile.c -93 +1 M ./ghc/rts/Sanity.c -7 +7 M ./ghc/rts/Schedule.c -3 +3 M ./ghc/rts/Sparks.c +10 M ./ghc/rts/Sparks.h -1 +4 M ./ghc/rts/Updates.h -18 +25 M ./mk/config.mk.in -6 +8 _______________________________________________ Cvs-ghc mailing list Cvs-ghc(a)haskell.org http://www.haskell.org/mailman/listinfo/cvs-ghc ===8<===========End of original message text=========== -- Best regards, Bulat mailto:bulatz@HotPOP.com

1 0

Re: [GHC] #683: RULES for recursive functions don't work properly
by Bulat Ziganshin 08 Feb '06

08 Feb '06

Hello GHC, Tuesday, February 07, 2006, 8:03:49 PM, you wrote: G> someone mentioned to me that this expression: G> mapM_ action [n..m] G> isn't being optimised properly, so I thought I'd look into it. Sure may be, what's me :) i use specially written function as faster version of this idiom and suggested Simon Marlow to substitute "mapM [n..m]" with call to my function using RULE mechanism -- Best regards, Bulat mailto:bulatz@HotPOP.com

2 2

bug in compacting GC
by Bulat Ziganshin 08 Feb '06

08 Feb '06

Hello , yes, i found this famous "-c" bug! the humor of situation is what easiest way to got this bug is to run ghc itself! :) it seems that noone except me tried this ever. i just found that any large enough module raises this error!!! that, for example, results of compiling Data.Map module: >ghc Map.hs -cpp +RTS -c ghc.EXE: internal error: update_fwd: unknown/strange object 39004 Please report this as a bug to glasgow-haskell-bugs(a)haskell.org, or http://www.sourceforge.net/projects/ghc/ ghc 6.4.1/mingw32. the error is absolutely reproducible, so at least now we had case, even lot of cases :) or you wanna a smaller program? :) -- Best regards, Bulat mailto:bulatz@HotPOP.com

2 3

RE: optimistic evaluation
by Simon Peyton-Jones 08 Feb '06

08 Feb '06

| What is the status of Rob Ennals' optimistic evaluation work? I'm told | that it has been removed from GHC. This is extremely depressing to me. More precisely, it never got into GHC. It was always on a heavily-modified branch. Rob's thesis was fantastic work. But although it sounded simple to start with, when he'd worked out all the details it was very, very complicated. Read his thesis! Simon and I decided that it was too big a complication to drag into our main compiler, and then maintain in perpetuity. It would not be so bad if it was a somewhat orthogonal feature, but it wasn't -- it percolated into many bits of the compiler and runtime system. It was cool stuff. Maybe bright person can figure out an easier way to do it. But I'm afraid we have no plans to incorporate it at the moment. Having said that, it wasn't a silver bullet! I very much doubt that it makes the difference between Haskell being usable for your work in machine learning, and not being usable. You may well need control over space, which is undoubtedly Haskell's weak spot. But remember, lazy evaluation can *reduce* space usage as well as increase it --- and the profiling tools plus seq and (perhaps!) bang patterns may give you the control you need. Simon

1 0

optimistic evaluation
by Frederik Eaton 08 Feb '06

08 Feb '06

Hi all, What is the status of Rob Ennals' optimistic evaluation work? I'm told that it has been removed from GHC. This is extremely depressing to me. Without such a feature available, it becomes very difficult to write programs that process large amounts of data in Haskell. In many such applications, strictness annotations become not just important for performance, but necessary to get a program to function at all. With optimistic evaluation, GHC and Haskell would have been at least potential candidates for my programming work in machine learning; without it I fear that this is no longer the case. Will optimistic evaluation ever be present in GHC again? What is its priority, compared to other features which are being implemented? What was the last (if any) version of GHC with optimistic evaluation present? Thanks, Frederik

2 3

RE: Re[2]: [GHC] #649: class declaration accepts conop as method name
by Simon Peyton-Jones 07 Feb '06

07 Feb '06

I agree 100% with you. We absolutely do intend to support 6.4.2 as a stable compiler for a long time yet. But this particular bug has been in the compiler for years, and only reported once. I very much doubt that anyone will even notice whether or not we fix 6.4.2. Still, if any two people (counting you as one) think they will notice, we'll certainly do it! Simon | -----Original Message----- | From: Bulat Ziganshin [mailto:bulatz@HotPOP.com] | Sent: 06 February 2006 19:39 | To: Simon Peyton-Jones | Cc: glasgow-haskell-users(a)haskell.org | Subject: Re[2]: [GHC] #649: class declaration accepts conop as method name | | Hello GHC, | | Monday, February 06, 2006, 7:59:24 PM, you wrote: | G> #649: class declaration accepts conop as method name | G> Type: bug | Status: closed | | G> Fixed in HEAD but wont't fix in 6.4.2 | | why you are not fixing this bug in 6.4.2? imho, we need to have more | stable GHC versions that can be used by the "real world" developers | like Joel Reymont just to work on their projects without reporting | each week new problem he is found in "stable" branch | | i/m trying to say that for wider GHC usage it should be more stable | than feature-rich and all new features that implemented in 6.4 or will | be implemented in 6.6 don't overweight for developers of large, | commercial apps importance of compiler stability and bug-free. i think | that GHC team should support previous version of compiler as long as | new version don't proved that it is bug-free. in this respect, even | 6.4 cannot be considered as stable version - it contains a number of | known and yet unfixed bugs and more arised as time goes. and at this | time you don't fix errors even in this version. so, that version of | GHC can be used to work on commercial projects? | | -- | Best regards, | Bulat mailto:bulatz@HotPOP.com | |

1 0

Re[2]: [GHC] #649: class declaration accepts conop as method name
by Bulat Ziganshin 06 Feb '06

06 Feb '06

Hello GHC, Monday, February 06, 2006, 7:59:24 PM, you wrote: G> #649: class declaration accepts conop as method name G> Type: bug | Status: closed G> Fixed in HEAD but wont't fix in 6.4.2 why you are not fixing this bug in 6.4.2? imho, we need to have more stable GHC versions that can be used by the "real world" developers like Joel Reymont just to work on their projects without reporting each week new problem he is found in "stable" branch i/m trying to say that for wider GHC usage it should be more stable than feature-rich and all new features that implemented in 6.4 or will be implemented in 6.6 don't overweight for developers of large, commercial apps importance of compiler stability and bug-free. i think that GHC team should support previous version of compiler as long as new version don't proved that it is bug-free. in this respect, even 6.4 cannot be considered as stable version - it contains a number of known and yet unfixed bugs and more arised as time goes. and at this time you don't fix errors even in this version. so, that version of GHC can be used to work on commercial projects? -- Best regards, Bulat mailto:bulatz@HotPOP.com

1 0