February 2010 - Glasgow-haskell-users

buildbot status
by Karel Gardas 14 Feb '10

14 Feb '10

Hello, as per GHC wiki (http://hackage.haskell.org/trac/ghc/wiki/BuildBot) its buildbot should be accessible either on http://darcs.haskell.org/buildbot or on http://darcs.haskell.org:8010. The first one return 404 page not found and the second tries to connect forever. May I ask what's the correct url for buildbot web page? Thanks, Karel

2 1

How to get the file descriptor of a handle?
by Volker Wysk 14 Feb '10

14 Feb '10

Hello I'd like to know how you get the file descriptor, which is incapsulated in a handle. The libraries GHC.IO.Handle/GHC.IO.Handle.FD only provide for the other direction. The function haFD, which I've used before I've updated to the current version of GHC (6.12), appears to be in use two times in the libraries. But there isn't a definition anywhere. Any help would be appreciated. Cheers, Volker -- Volker Wysk <pf3(a)volker-wysk.de>

2 1

Fw: Re: Re[2]: No more ExitException? <- documentation bug
by Volker Wysk 13 Feb '10

13 Feb '10

The following message went to Bulat Ziganshin alone. So here it is for the mailing list. Sorry. Begin forwarded message: On Wed, 27 Jan 2010 12:43:13 +0300 Bulat Ziganshin <bulat.ziganshin(a)gmail.com> wrote: > > exitWith throws the ExitCode when it is called. This leads to the > > shutdown of the program, if it isn't caught. Just like ExitException. > > > This isn't documented. > > i've googled for "exitWith throws the ExitCode" and it pointed me to > the exitWith docs: "Computation exitWith code throws ExitException code." This is the source code of exitWith: -------------------------snip----------------------------- -- --------------------------------------------------------------------------- -- exitWith -- | Computation 'exitWith' @code@ throws 'ExitException' @code@. -- Normally this terminates the program, returning @code@ to the -- program's caller. Before the program terminates, any open or -- semi-closed handles are first closed. -- -- A program that fails in any other way is treated as if it had -- called 'exitFailure'. -- A program that terminates successfully without calling 'exitWith' -- explicitly is treated as it it had called 'exitWith' 'ExitSuccess'. -- -- As an 'ExitException' is not an 'IOError', 'exitWith' bypasses -- the error handling in the 'IO' monad and cannot be intercepted by -- 'catch' from the "Prelude". However it is an 'Exception', and can -- be caught using the functions of "Control.Exception". This means -- that cleanup computations added with 'Control.Exception.bracket' -- (from "Control.Exception") are also executed properly on 'exitWith'. #ifndef __NHC__ exitWith :: ExitCode -> IO a exitWith ExitSuccess = throwIO ExitSuccess exitWith code@(ExitFailure n) | n /= 0 = throwIO code #ifdef __GLASGOW_HASKELL__ | otherwise = ioError (IOError Nothing InvalidArgument "exitWith" "ExitFailure 0" Nothing) #endif #endif /* ! __NHC__ */ -------------------------snip----------------------------- As you can see, it throws the ExitCode, not an ExitException. The documentation is faulty. Cheers, Volker -- Volker Wysk <vw(a)volker-wysk.de> -- Volker Wysk <vw(a)volker-wysk.de>

2 1

Overlapping Instances + Existentials = Incoherent Instances
by Dan Doel 10 Feb '10

10 Feb '10

Greetings, I've actually known about this for a while, but while discussing it, it occurred to me that perhaps it's something I should report to the proper authorities, as I've never seen a discussion of it. But, I thought I'd start here rather than file a bug, since I'm not sure it isn't intended. Anyhow, here's the example: class C a where foo :: a -> String instance C a where foo _ = "universal" instance C Int where foo _ = "Int" bar :: a -> String bar x = foo x Now, normally bar generates a complaint, but if you enable IncoherentInstances, it's accepted, and it always generates "universal", even if called with an Int. Adding a 'C a' constraint to the type makes it give "Int" in the case of an Int. Now, IncoherentInstances is something most people would suggest you don't use (even people who are cool with OverlappingInstances). However, it turns out that ExistentialQuantification does the same thing, because we can write: data Ex = forall a. Ex a baz :: a -> String baz x = case Ex x of Ex x' -> foo x' and this is accepted, and always yields "universal", just like bar. So, things that you get out of an existential are allowed to make use of the general versions of overlapping instances if any fit. So, I never really regarded this as anything more than an oddity that's unlikely to come up. And it might be working as intended. But I thought perhaps I should ask: is this intended? One could probably build a case that baz should only be accepted if IncoherentInstances are enabled, since it's doing about the same thing. I'm not really sure how far back this behavior goes. I've probably known about it for several 6.X releases without mentioning it except as a fun party fact (apologies). Is this the way things are supposed to work? (And sorry if I just missed the discussion somewhere. I searched the trac and didn't see anything very promising.) Cheers, -- Dan

3 3

Update on GHC 6.12.1
by Simon Peyton-Jones 09 Feb '10

09 Feb '10

Folks This is an update on the status of GHC 6.12. FIRST, as you probably know, Hackage and the Haskell Platform is allowing GHC HQ to get out of the libraries business. So the plan is - We release GHC 6.12 with very few libraries - Bill Library Author downloads GHC 6.12 and tests his libraries - The next Haskell Platform release packages GHC 6.12 with these tested libraries - Joe User downloads the Haskell Platform. - Four months later there's a new HP release, still with GHC 6.12, but with more or better libraries. The HP release cycle is decoupled from GHC So if you are Joe User, you want to wait for the HP release. Don't grab the GHC 6.12 release. It'll be perfectly usable, but only if you use (an up to date) cabal-install to download libraries, and accept that they may not be tested with GHC 6.12. SECOND, we have produced Release Candidate 1 for GHC 6.12.1, and are about to produce RC2. However, before releasing 6.12 we'd like to compile all of Hackage, in case doing so reveals bugs in GHC's APIs (which are not supposed to change). But we can't do that until an update to cabal-install is ready. (We don't expect this dependency to happen all the time, but it does hold for 6.12.) Duncan has been working on the cabal-install update, and expects to release by end November. So the timetable looks like this: - Very soon: GHC 6.12.1 release candidate 2 - End Nov: cabal-install release - ...test GHC against Hackage... - Early Dec: release GHC 6.12 - ...library authors and HP folk get busy... - End Jan (?): Haskell Platform release - ...Joe User downloads HP... FINALLY, below I summarise a late change that's been pending for a long time, which I propose to sneak into RC2, for reasons explained below. If you can see a good reason not to do this, yell. Simon Recursive do-notation. ~~~~~~~~~~~~~~~~~~~~~~ The change is this. Instead of writing mdo { a <- getChar ; b <- f c ; c <- g b ; putChar c ; return b } you would write do { a <- getChar ; rec { b <- f c ; c <- g b } ; putChar c ; return b } That is, * 'mdo' is eliminated * 'rec' is added, which groups a bunch of statements into a single recursive statement See http://hackage.haskell.org/trac/ghc/ticket/2798 This 'rec' thing is already present for the arrow notation, so it makes the two more uniform. Moreover, 'rec' lets you say more precisely where the recursion is (if you want to), whereas 'mdo' just says "there's recursion here somewhere". Lastly, all this works with rebindable syntax (which mdo does not). Currently 'mdo' is enabled by -XRecursiveDo. So we propose to deprecate this flag, with another flag -XDoRec to enable the 'rec' keyword. The main question is not whether to make this change, but when. I'm inclined to do put it into GHC 6.12, even though it's late in the day because then we can take mdo out of 6.14 altogether. Another minor question is whether "-XDoRec" is a good name for the flag. We can't really use "-XRecursiveDo" because that's the one we are deprecating!

12 18

Undeliverable: Splicing types.. should this work?
by Simon Peyton-Jones 09 Feb '10

09 Feb '10

Robert Interesting example. Here's your code: createInstance' :: Q Type -> Q Dec createInstance' t = liftM head [d| instance Foo $t where type FooType $t = String |] When TH sees a quotation, it *typechecks* it. So it tries to typecheck instance Foo $t where type FooType $t = String During typechecking, it needs something to use as the type to which $t will expand. So it uses a fresh type variable -- but a different one each time. And this is what is biting you. In general that's right. You would not expect it to work if you said instance Foo $(t 19) where type FooType $(t 19) = String seeing that 't' is applied to the same argument each time. There no special case for plain variables. So it's hardly a feature, but I can't see how to do just what you want. Simon | -----Original Message----- | From: glasgow-haskell-users-bounces(a)haskell.org [mailto:glasgow-haskell-users- | bounces(a)haskell.org] On Behalf Of Robert Greayer | Sent: 25 January 2010 23:27 | To: glasgow-haskell-users(a)haskell.org | Subject: Splicing types.. should this work? | | Now that type-splicing works in TH, and TH has type-family support, I | was wondering if the following example should compile (with 6.12.1): | | > {-# LANGUAGE TemplateHaskell, MultiParamTypeClasses, TypeFamilies, | > FlexibleInstances, OverlappingInstances #-} | | > module Sample where | | > import Control.Monad | > import Language.Haskell.TH | | > class Foo a where | > type FooType a | | > createInstance :: Q Type -> Q Dec | | > createInstance t = instanceD (return []) | > (conT ''Foo `appT` t) [ | > tySynInstD ''FooType [t] (conT ''String) | > ] | | > createInstance' :: Q Type -> Q Dec | > createInstance' t = liftM head [d| | > instance Foo $t where | > type FooType $t = String|] | | the function 'createInstance' compiles without a problem, but it's | (near) equivalent | written using TH quotations + splices fails with the error: | | Sample.lhs:22:10: | Type indexes must match class instance head | Found `t_aMn' but expected `t_aMl' | In the associated type instance for `FooType' | In the instance declaration for `Foo $t' | In the Template Haskell quotation | [d| | instance Foo $t where | type instance FooType $t = String |] | | The compiler seems to not be able to determine that the type spliced | in the class instance head will match the type spliced in the type | instance. | | The first version works fine for my purposes, but was curious whether | the failure of the 2nd was a bug or a feature. | | Thanks, | Rob | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

1 0

Text.Regex.Posix with [String] Result broken?
by Christian Höner zu Siederdissen 08 Feb '10

08 Feb '10

Hi, are Regex'es broken or is this local to my installation? I want to blame someone else, see: http://book.realworldhaskell.org/read/efficient-file-processing-regular-exp… where all result types of [a] are broken, too. Thanks, Christian What to test for: Prelude> :m Text.Regex.Posix Prelude Text.Regex.Posix> "aab" =~ "a" :: String "a" Prelude Text.Regex.Posix> "aab" =~ "a" :: [String] <interactive>:1:0: No instance for (RegexContext Regex [Char] [String]) arising from a use of `=~' at <interactive>:1:0-11 Possible fix: add an instance declaration for (RegexContext Regex [Char] [String]) In the expression: "aab" =~ "a" :: [String] In the definition of `it': it = "aab" =~ "a" :: [String]

1 0

Fwd: Still causes segfault.
by Marco Túlio Gontijo e Silva 08 Feb '10

08 Feb '10

--- Begin forwarded message from Marco Túlio Gontijo e Silva --- From: Marco Túlio Gontijo e Silva <marcot(a)riseup.net> To: 557185 <557185(a)bugs.debian.org> Cc: debian-haskell <debian-haskell(a)lists.debian.org>, glasgow-haskell-users <glasgow-haskell-users(a)lists.debian.org> Date: Fri, 05 Feb 2010 15:26:51 -0200 Subject: Still causes segfault. Hi. I just tested building ghc6-6.12.1-4_powerpc with a registered build, that is, without those lines from debian/rules that make an unregistered build, and got a segfault just after running inplace/bin/ghc-stage2 --interactive. Just confirming that this bug is still present in this version. Greetings. --- End forwarded message --- -- marcot http://marcot.iaaeee.org/

3 2

DPH and CUDA status
by Felipe Lessa 08 Feb '10

08 Feb '10

Hello, Recently I tried to look for the status of Data Parallel Haskell with a CUDA backend. I've found [1] which mentions [2] saying that this is difficult and work was being done. That was almost two years ago. Was any progress made since then or is the work stalled? About GSoC, I wonder if there is any part of the ticket that can be done in a summer's worth of time? Thanks, guys! :) [1] http://hackage.haskell.org/trac/summer-of-code/ticket/1537 [2] http://article.gmane.org/gmane.comp.lang.haskell.cafe/37538 -- Felipe.

8 12

keyword in pragma
by Serge D. Mechveliani 07 Feb '10

07 Feb '10

In my last letter I wrote about the prossibility for the GHC developers to require a keyword in any pragma, "for future". I thought that pragma is a matter of the GHC language extension. But if it is of the Haskell standard, then, again I am sorry! Regards, ----------------- Serge Mechveliani mechvel(a)botik.ru

1 0