- Glasgow-haskell-users

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

Re: forgetting SCC
by Serge D. Mechveliani 07 Feb '10

07 Feb '10

I am sorry, indeed, ghc-6.12.1 warns of Unrecognised pragma on {-# "foo" #-}. I have just missed this warning. The next question is: why it is a warning and not an error break? ----------------- Serge Mechveliani mechvel(a)botik.ru On Sun, Feb 07, 2010 at 10:56:53AM +0000, Ian Lynagh wrote: > On Sun, Feb 07, 2010 at 11:39:31AM +0300, Serge D. Mechveliani wrote: > > On Sat, Feb 06, 2010 at 08:24:07PM +0000, Ian Lynagh wrote: > > > On Sun, Jan 31, 2010 at 10:09:42PM +0300, Serge D. Mechveliani wrote: > > > > I have a suggestion: > > > > is it better for GHC to report an error on the source of kind > > > > {-# "foo" #-} > > > > (entered by a typo instead of {-# SCC "foo" #-}) ? > > > > Currently, GHC makes the program under (-prof) in which, the "foo" center > > > > occurs skipped. This misleads the user: > > > > "foo is not in the profiling head, so it takes zero cost". > > > > > > 6.12.1 will warn: > > > > > > q.hs:3:0: Unrecognised pragma > > > > > > by default. > > > > May be, you mean the version next to 6.12.1 ? > > Because this my report is exactly on 6.12.1. > > No, in 6.12.1: > > $ cat Q.hs > > module Q where > > {-# "foo" #-} > > $ ghci Q.hs > GHCi, version 6.12.1: http://www.haskell.org/ghc/ :? for help > Loading package ghc-prim ... linking ... done. > Loading package integer-gmp ... linking ... done. > Loading package base ... linking ... done. > Loading package ffi-1.0 ... linking ... done. > [1 of 1] Compiling Q ( Q.hs, interpreted ) > > Q.hs:4:0: Unrecognised pragma > Ok, modules loaded: Q. > *Q> > > > Thanks > Ian > >

2 4

forgetting SCC
by Serge D. Mechveliani 06 Feb '10

06 Feb '10

I have a suggestion: is it better for GHC to report an error on the source of kind {-# "foo" #-} (entered by a typo instead of {-# SCC "foo" #-}) ? Currently, GHC makes the program under (-prof) in which, the "foo" center occurs skipped. This misleads the user: "foo is not in the profiling head, so it takes zero cost". Regards, ----------------- Serge Mechveliani mechvel(a)botik.ru

2 1

Quasi quoting
by Simon Peyton-Jones 06 Feb '10

06 Feb '10

Dear GHC users This email is to announce two proposed changes to GHC's quasi-quotation mechanism. For all I know, no one is using quasi-quotation (although it's a very cool feature, thanks to Geoff Mainland), but I didn't think I should take it for granted! The current spec is here: http://haskell.org/haskellwiki/Quasiquotation http://www.haskell.org/ghc/docs/latest/html/users_guide/template-haskell.ht… A quasi-quote can appear as a (a) expression (b) pattern, and looks like this [$pads| ...blah... |] where 'pads' (of course any name will do) is a record of functions data QuasiQuoter = QuasiQuoter { quoteExp :: String -> Q Exp quotePat :: String -> Q Pat } The idea is that GHC evaluates (pads "...blah..."), and splices in the resulting Exp (or Pat) just as if that's what the user wrote in the first place. Kathleen Fisher has started to use this for her PADS system, and came up with two suggestions. 1. Allow quasi-quotes at the (top-level) declaration level, just like TH splices. So you could say, at top level [$pads| ...blah... |] and have it expand to a bunch of top level Haskell declarations. This seems like an unconditionally good idea. To support it we'd need to add a field to QuasiQuoter: data QuasiQuoter = QuasiQuoter { quoteExp :: String -> Q Exp quotePat :: String -> Q Pat quoteDec :: String -> Q [Dec] } but I don't think anyone will lose sleep over that. 2. Make the notation less noisy for the "customer". In particular, that '$' is scary, and redundant to boot. She would like to write [pads| ...blah... |] I can see the motivation here, but there are two reasons for caution. (i) The Template Haskell quote forms [t| ... |] and [d| ... |] behave rather differently. (ii) If "[pads|" is a lexeme, then some list comprehensions become illegal, such as [x|x<-xs,y<-ys]. But note that because of Template Haskell quotations, a comprehension [t|t<-ts] is already broken, and similarly with 'd', 'e'. So the proposed change will make things *more* uniform, by grabbing every "[blah|" as lexeme. For me (i) is the main issue. The differences are significant. - A TH quote can appear only where an *expression* is expected But a quasiquote can be an expression or pattern or (assuming (1)) declaration - A TH quote has type (Q Typ) or (Q [Dec]) or (Q Exp) But a quasiquote is run immediately and spliced in place of the quote - A TH splice is run during type checking But a quasiquote is run during renaming Even given all that, I'm strongly inclined to follow Kathleen's suggestion: - The differences are there all right, but in some ways the programmer thinks the same way: [lang| blah |] switches to language 'lang'. - Many users will never encounter the issue; they'll just say [pads| blah |] to wake up the PADS magic, and be oblivious to Template Haskell quotes An alternative would be to have some other cue. Ones I've considered - $[pads| ...|], but allowing the $ to be omitted on top-level declarations, top level, just as it now can for TH splices. - [pads:| ... |], with the colon distinguishing quasi-quoting from TH. My gut feel is to go with [|pads| ... |]. Of course this'd be a change from the current syntax, but I think there are few enough users that they'll switch easily enough. Any comments on any of this? Simon

14 27

Template Haskell pattern quotations
by Brad Larsen 04 Feb '10

04 Feb '10

I'll put my question at the very front of this message, and then give the context. My question: Are Template Haskell pattern quotations (i.e., [p| ... |]) not implemented in GHC because they are rather tricky to implement, or because there has not been demand for them? And now, the context. I am working on an embedded DSL/compiler in Haskell, and I want to make use of the recently-much-discussed quasiquoting mechanism to ease reading & writing various transformations. I read through the quasiquoting paper [1] again and played around with some simple examples. In the paper, Data.Generics is used so that the same parser can be used for quasiquoting both expressions and patterns. This requires adding constructors to the ASTs being quasiquoted for antiquotations to be possible. In my application, I don't anticipate using Data.Generics for parser reuse, for a few reasons: * I haven't read the SYB papers, and don't understand how Data.Generics or Data.Data work. * My ASTs in some cases involve GADTs with several phantom type parameters (is that the right terminology?), and DeriveDataTypeable does not work with them. * I don't want to add the extra constructors necessary to support antiquotation with the Data.Generics approach. So, I'm stuck writing separate ExpQ / PatQ parsers. (Actually, I can write the parser once, if it takes a dictionary of semantic actions as a parameter, in which case I only need to write the dictionary of ExpQ actions and the dictionary of PatQ actions.) When writing the ExpQ parser, I can use Template Haskell expression quotations, [| ... |]. When writing the PatQ parser, I have to resort to using the various pattern construction combinators, which is unfortunate! I'd like to be able to use pattern quotations instead. So, my question once again: How hard would it be to implement the pattern quotations from the Template Haskell paper in GHC? Sincerely, Brad References: [1] Geoffrey B. Mainland. Why It's Nice to be Quoted: Quasiquoting for Haskell. <http://www.eecs.harvard.edu/~mainland/ghc-quasiquoting/mainland07quasiquoti…>

4 5