- Glasgow-haskell-users

Re: Control.Exception
by shelarcy 04 Nov '08

04 Nov '08

On Tue, 04 Nov 2008 19:41:58 +0900, Duncan Coutts <duncan.coutts(a)comlab.ox.ac.uk> wrote: >> >> action >> >> `catches` >> >> [ \(e :: ExitCode) -> ... >> >> , \(e :: PatternMatchFail) -> ... >> >> ] >> >> >> >> or just by using multiple catch clauses: >> >> >> >> action >> >> `catch` (\(e :: ExitCode) -> ...) >> >> `catch` (\(e :: PatternMatchFail) -> ...) >> > >> > I don't think those are equivalent. In the second case, the >> > PatternMatchFail handler scopes over the ExitCode handler. >> >> I think Duncan forgot to write parens. According to Ian's example, >> here is an equivalent code. >> >> (action >> `catch` (\(e :: ExitCode) -> ...)) >> `catch` (\(e :: PatternMatchFail) -> ...) > > David is right. If the exit code handler throws a pattern match > exception then the code behaves differently than the `catches` version. I see. I misunderstood the problem. Thanks, -- shelarcy <shelarcy hotmail.co.jp> http://page.freett.com/shelarcy/

1 0

ANNOUNCE: GHC 6.10.1 RC 1
by Ian Lynagh 03 Nov '08

03 Nov '08

We are pleased to announce that the GHC 6.10.0.20081007 snapshot is the first release candidate for GHC 6.10.1. You can download the release candidate from here: http://www.haskell.org/ghc/dist/stable/dist/6.10.1-rc-1/rc.html This page includes: * a Windows installer * an OS X installer * bindists for amd64/Linux and ix86/Linux * the sources There is also a status page here: http://hackage.haskell.org/trac/ghc/wiki/GHC-6.10.1 where we will keep track of where the RC works, and where it is known to have problems. This is a wiki page, so please feel free to update it if you are able to add or update the information on a particular platform. Please test as much as possible; bugs are much cheaper if we find them before the release! We hope that we will be able to make the final release in around one weeks time, but of course that may slip if problems are uncovered. Thanks Ian, on behalf of the GHC team

8 15

Dilemma: DiffArray non-performance vs STArray non-readability
by Claus Reinke 03 Nov '08

03 Nov '08

I keep wanting to use DiffArray as the natural functional solution to single-threaded array use. But everytime I try, I get smacked over the head with the actual performance figures. Sometimes, even plain arrays are faster in a loop doing array updates, in spite of all the copying involved. And when copying on update dominates the runtime, using IntMap tends to be faster - the "indirections" are the wrong way round, but don't pile up, just that array lookups aren't quite constant time. But when I really need to avoid the updates, and need constant time lookup, I'm stuck: DiffArray tends to slow everything down (I vaguely recall locks and threads being at the heart of this, but I haven't checked the code recently), so my only option seems to be to transform my nice functional code into not-nice sequential code and use STArray. Is there any way out of this dilemma? What do other Ghc users use? If locks really are the issue, perhaps using STM instead of MVars in the DiffArray implementation could help. As long as my array uses are single-threaded, STM optimism might be able to avoid waiting/scheduler issues? Or am I on the wrong track? Claus PS Btw, I thought the DiffArray performance issue was ancient, but I can't find a ticket for it, nor does the haddock page for Data.Array.Diff mention this little hickup. Should I add a ticket?

4 4

cabal
by Christian Maeder 01 Nov '08

01 Nov '08

Hi, currently I've got a problem installing from hackage. using: GHC (package manager) version 6.10.0.20081019 cabal-install version 0.6.0 using version 1.6.0.1 of the Cabal library I get: Building network-2.2.0.0... Network/URI.hs:128:7: Could not find module `Data.Generics': it is a member of package base-3.0.3.0, which is hidden even with: cabal install network --constrain="base<4" (A similar problem happened with Shellac.) How is the smart selection between base-3 and base-4 going to work? Eventually, I want to install hxt-filter and Shellac-compatline. (The interface in editline changed for Shellac-editline.) Cheers Christian

4 6

file descriptors
by Johannes Waldmann 31 Oct '08

31 Oct '08

Dear all, are there any known issues with file handles/descriptors in ghc-compiled executables? My program has a lot of calls to System.Process.runInteractiveProcess and I'm running into unpredictable behaviour (sometimes the program just silently dies, sometimes it gets stuck) The handles I get correspond to file descriptors in the OS? Could there be any conflicts? (Like not enough available, or re-used to early etc.) Or perhaps you see anything that's wrong with my code here http://dfa.imn.htwk-leipzig.de/cgi-bin/cvsweb/box/src/SMT/Time.hs?rev=1.9 I'm compiling this with -threaded, but running with -N1. Of course, terminateProcess is another source of uncertainty here. (Sometimes it takes several seconds until the external process dies.) Any hints appreciated. - J.W.

3 2

gadt changes in ghc 6.10
by Daniel Gorín 30 Oct '08

30 Oct '08

Hi After installing ghc 6.10-rc, I have a program that no longer compiles. I get the dreaded "GADT pattern match...." error, instead :) Here is a boiled-down example: {-# OPTIONS_GHC -XGADTs -XEmptyDataDecls #-} module T where data S data M data Wit t where S :: Wit S M :: Wit M data Impl t a where I1 :: Maybe a -> Impl S a I2 :: [a] -> Impl M a type W_ t a = Wit t -> Impl t a newtype W t a = Wrap (W_ t a) bind :: W t a -> (a -> W t b) -> W_ t b bind (Wrap w) f = \wit -> case wit of S -> case w S of I1 m -> I1 $ do a <- m case f a of Wrap w' -> case w' S of I1 m' -> m' M -> case w M of I2 m -> I2 $ do a <- m case f a of Wrap w' -> case w' M of I2 m' -> m' While in ghc 6.8.3 this compiles fine, with ghc 6.10 i get: $ ghc --make T.hs [1 of 1] Compiling T ( T.hs, T.o ) T.hs:26:57: GADT pattern match with non-rigid result type `Maybe a' Solution: add a type signature In a case alternative: I1 m' -> m' In the expression: case w' S of { I1 m' -> m' } In a case alternative: Wrap w' -> case w' S of { I1 m' -> m' } I've tried adding some signatures (together with - XScopedTypeVariables), but with no luck. Why is it that this no longer compiles? More importantly, how can I make it compile again? :) Thanks! Daniel

4 8

RE: Type classes in GADTs
by C Rodrigues 30 Oct '08

30 Oct '08

Thanks for the explanation. I see how this wouldn't behave nicely with automatic class constraint inference. I didn't test the example on any other GHC versions. I will probably end up passing in the Eq dictionary from outside like Daniil suggested. I would prefer to do the following, but GHC doesn't accept the type signature. evidenceOfEq :: CAOp a -> (Eq a => b) -> b Neither does it accept data EqConstraint a b = EqConstraint (Eq a => b). Foiled again. _________________________________________________________________ Want to read Hotmail messages in Outlook? The Wordsmiths show you how. http://windowslive.com/connect/post/wedowindowslive.spaces.live.com-Blog-cn…

2 1

Type classes in GADTs
by C Rodrigues 30 Oct '08

30 Oct '08

I discovered that closed type classes can be implicitly defined using GADTs. The GADT value itself acts like a class dictionary. However, GHC (6.8.3) doesn't know anything about these type classes, and it won't infer any class memberships. In the example below, an instance of Eq is not recognized. So is this within the domain of GHC's type inference, not something it shoud infer, or a bug? {-# OPTIONS_GHC -XTypeFamilies -XGADTs -XEmptyDataDecls #-} module CaseAnalysisOnGADTs where -- Commutative and associative operators. data CAOp a where Sum :: CAOp Int Disj :: CAOp Bool Concat :: CAOp String {- For any non-bottom value of type 'CAOp a', the value will have type -- CAOp Int, CAOp Bool, or CAOp String. Int, Bool, and String are all -- members of Eq. Therefore, if we have a non-bottom value of type -- 'CAOp a' then 'a' is a member of Eq. -} data D a = D !(CAOp a) (a, a) -- However, GHC won't figure this out. noEvidenceOfEq :: D a -> Bool noEvidenceOfEq (D op (e1, e2)) = e1 == e2 -- Error, no instance (Eq a) -- Unless you force it to do case analysis on constructors. evidenceOfEq :: CAOp a -> a -> a -> Bool evidenceOfEq Sum = (==) evidenceOfEq Disj = (==) evidenceOfEq Concat = (==) -- Then you can use the result from that, but GHC still won't -- recognize it as an Eq instance. useEvidenceOfEq :: D a -> Bool useEvidenceOfEq (D op (e1, e2)) = evidenceOfEq op e1 e2 _________________________________________________________________ You live life beyond your PC. So now Windows goes beyond your PC. http://clk.atdmt.com/MRT/go/115298556/direct/01/

3 2

Re: [Haskell-cafe] Re: ghc-6.11 + OpenGL/GLUT crashes on WinXP
by Conal Elliott 29 Oct '08

29 Oct '08

No display lists. The crash happens during the GLUT call "initialize". I can trigger it from ghci with the following simple incantation: Prelude> import Graphics.UI.GLUT Prelude Graphics.UI.GLUT> initialize "foo" [] And no trouble under ghc 6.9.20080622. Stumped. :( - Conal On Tue, Oct 28, 2008 at 3:14 PM, Jefferson Heard < jefferson.r.heard(a)gmail.com> wrote: > Conal, are you using display lists at all? I've had problems with > allocating lists, but you seem to be able to leave off the allocation > step in Windows on nVidia cards so long as you're careful not to > conflict names yourself. > > On Tue, Oct 28, 2008 at 4:03 PM, Matti Niemenmaa > <matti.niemenmaa+news(a)iki.fi <matti.niemenmaa%2Bnews(a)iki.fi>> wrote: > > Conal Elliott wrote: > >> I am using glut32 rather than freeglut (and no need for patching the > darcs > >> GLUT). I wonder if glut32-vs-freeglut could account for > crash-vs-nocrash on > >> 6.10 and 6.11 but not 6.9. I'd love to hear from someone on Windows and > >> glut32. > > > > Windows XP with SP3 > > ghc-6.10.20081007 > > glut32 > > > > Works fine for me. > > > > Taking a look at my GL headers, I did have to mess with at least glut.h > to get > > something to work---whether it was to build HOpenGL, to make programs > linkable, > > or to make them runnable, I'm not sure. In any case, what I did was force > > GLUTAPIENTRY to be #defined as __stdcall. > > > > _______________________________________________ > > Haskell-Cafe mailing list > > Haskell-Cafe(a)haskell.org > > http://www.haskell.org/mailman/listinfo/haskell-cafe > > > > > > -- > I try to take things like a crow; war and chaos don't always ruin a > picnic, they just mean you have to be careful what you swallow. > > -- Jessica Edwards > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe >

1 0

Subtle difference between standard instances
by David Sankel 28 Oct '08

28 Oct '08

We, at Anygma, noticed that a and b below have different behavior: a, b :: (Int->Int) -> (Int,Int) -> (Int,Int) a = fmap b = second See the blog post at http://netsuperbrain.com/blog/?p=74. The standard instances for Functor, Monad, and Applicative for tuples is strict. The Arrow on (->) when applied to tuples with first and second, however is non-strict. It is a subtle discrepancy, but it does make a difference for FRP when deriving these standard instances. Any objections to making the Functor, Monad, and Applicative instances for tuples non-strict like Arrows? David

2 1