- Glasgow-haskell-users

ghc 6.10.4 infix declarations and '\' bug or not ?
by John Lask 23 Aug '09

23 Aug '09

in declaring fixity for an operator (\\) to get it to compile using ghc 6.10.4, I needed to use the following code infixl 9 \\\ (\\) a b = etc ... where I assume the first \ escapes the second \, using infixl 9 \\ generates a syntax error infixl 9 \\ used to compile no problems with ghc 6.8.2 what is going on here ? why do I now need to add an additional \ ?, where is this change documented ?, is this a bug?

2 2

RE: [Haskell-cafe] generalize RecordPuns and RecordWildCards to work with qualified names?
by Simon Peyton-Jones 20 Aug '09

20 Aug '09

Evan, Lennart Thanks for the provocation. I've committed a patch that fixes all these issues. Try now! Simon Thu Aug 20 13:34:43 BST 2009 simonpj(a)microsoft.com * Improvements to record puns, wildcards * Make C { A.a } work with punning, expanding to C { A.a = a } * Make it so that, with -fwarn-unused-matches, f (C {..}) = x does not complain about the bindings introduced by the "..". * Make -XRecordWildCards implies -XDisambiguateRecordFields. * Overall refactoring of RnPat, which had become very crufty. In particular, there is now a monad, CpsRn, private to RnPat, which deals with the cps-style plumbing. This is why so many lines of RnPat have changed. * Refactor the treatment of renaming of record fields into two passes - rnHsRecFields1, used both for patterns and expressions, which expands puns, wild-cards - a local renamer in RnPat for fields in patterns - a local renamer in RnExpr for fields in construction and update This make it all MUCH easier to understand * Improve documentation of record puns, wildcards, and disambiguation | -----Original Message----- | From: haskell-cafe-bounces(a)haskell.org [mailto:haskell-cafe-bounces@haskell.org] On | Behalf Of Evan Laforge | Sent: 12 August 2009 23:59 | To: Simon Peyton-Jones | Cc: Augustsson, Lennart; haskell; GHC users | Subject: Re: [Haskell-cafe] generalize RecordPuns and RecordWildCards to work with | qualified names? | | > | Even is suggesting that instead of reporting an error, in the second | > | case we could use the translation: | > | | > | f (A.A { A.a }) = a --> f (A.A { A.a = a }) | > | | > | (i.e., when punning occurs with a qualified name, use just the | > | unqualified part of the name in the pattern) | > | > Yes, that'd be possible. But it seems debatable -- it doesn't *look* as if the | pattern (A.A { A.a }) binds 'a' -- and it seems even less desirable in record | construction and update. To be concrete, would you expect these to work too? | > | > g a = A.A { A.a } --> g a = A.A { A.a = a } | > h x a = x { A.a } --> h x a = a { A.a = a } | | Oh, I didn't realize that record punning included construction as | well. Yeah, that's a little funky looking. I don't mind seeing the | binding form and I think a new reader could figure it out without too | much trouble but I would be a little confused by the construction form | and think a new reader would also be confused. | | > With -XDisambiguateRecordFields you could say | > | > g a = A.A { a } | > | > which seems better. (But there's no help for record update, since we don't know | which data constructor is involved.) | | I didn't know about DisambiguateRecordFields! Looks like that also | makes the wildcard work like I want it to. | | The ghc docs for DisambiguateRecordFields don't make this very clear | to me... it talks about disambiguating names in scope, but if I say | "R.R { a = val}" I wouldn't expect it to "disambiguate" 'a', which is | not in scope at all, to 'R.a' which looks like a completely different | name. Rereading the paragraph at 7.3.11 I'm still surprised this | works. Maybe add something like: | | ... preceeding docs ... | | This also means that if you use qualified imports you can still use | unqualified field names. E.g. in the pattern @(R.R { a = a_val })@, | @a@ will be disambiguated to @R.a@, even if @R@ is imported qualified. | | I gather we're not supposed to call them "records" anymore, they're | supposed to be something I forget now, but the rest of the ghc docs | says records, so... | | > So my current conclusion is: improve the error message, perhaps suggesting the | flag -XDismabiguateRecordFields, but don't add the change you suggest. | > | > Comments? | | Sounds good to me. I'll try adding DisambiguateRecordFields and try | out the new punning, thanks! | _______________________________________________ | Haskell-Cafe mailing list | Haskell-Cafe(a)haskell.org | http://www.haskell.org/mailman/listinfo/haskell-cafe

1 0

Building just a stage 1 compiler?
by Tim Chevalier 19 Aug '09

19 Aug '09

Hi, Is there a way to tell the GHC build system that I only want to build a stage 1 compiler and the libraries, not a stage 2 compiler? Executing: $ sh boot $ ./configure $ make stage=1 in my build tree still builds the stage 2 compiler as well. Thanks, Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc/ * Often in error, never in doubt

3 2

Generating valid Haskell code using the GHC API pretty printer
by Jan Schaumlöffel 18 Aug '09

18 Aug '09

Hello everyone, we are trying to use the GHC API for a source-to-source transformation on Haskell programs. The result of parsing and typechecking a module enables us to apply the transformation, but writing the transformed module back using the pretty printer (Outputable) generates invalid Haskell code. For one thing, since even the names defined in the current module are fully qualified, the resulting code is not valid anymore. This can be worked around, but there is another issue: Simply reading the following program and then writing it out using the pretty printer renders the resulting code invalid. > module Main where > main = do > if True then putStrLn "longlonglonglonglonglongline" > else return () > longlonglonglonglonglonglonglonglonglonglonglongname $ "test" > longlonglonglonglonglonglonglonglonglonglonglongname = putStrLn The result looks like this: > Main.main = do if GHC.Bool.True then > System.IO.putStrLn "longlonglonglonglonglongline" > else > GHC.Base.return () > Main.longlonglonglonglonglonglonglonglonglonglonglongname > GHC.Base.$ > "test" > Main.longlonglonglonglonglonglonglonglonglonglonglongname = System.IO.putStrLn There are two different problems in this output: 1) the indentation of "if ... then ... else" violates the "do"-block layout rule 2) the indentation of the long function call is invalid It looks like those problems could be avoided if the pretty printer could be configured to consistently use "do { ... ; ... }" notation, but we have been unable to figure out how. Is there a canonical way to use the GHC API to pretty print to valid Haskell code? Kind regards, Jan Appended is our current code to execute the transformation above (the module to be read is expected in a file "dummy.hs" for simplicity). Please excuse if this might not be a minimal example. module Main where import GHC import GHC.Paths import Outputable main = do x <- runGhc (Just libdir) $ do dflags <- getSessionDynFlags setSessionDynFlags (dflags { hscTarget = HscNothing, ghcLink = NoLink }) target <- guessTarget "dummy.hs" Nothing setTargets [target] load LoadAllTargets graph <- getModuleGraph let unparsedmod = head graph parsedmod <- parseModule unparsedmod typecheckedmod <- typecheckModule parsedmod let Just renamedsource = renamedSource typecheckedmod (group,_,_,_,_) = renamedsource moduledings = (ms_mod unparsedmod) return (showSDoc (ppr group)) putStr $ x ++ "\n" -- If you're happy and you know it, syntax error!

3 3

what is the path to a particular module?
by S. Alexander Jacobson 15 Aug '09

15 Aug '09

Is there a way from GHCi to discover the path to a particular module that you have imported or loaded? -Alex-

3 2

FFI: Problem with Signal Handler Interruptions
by Levi Greenspan 15 Aug '09

15 Aug '09

Apologies for re-posting this subject here since I had sent already a message to haskell-café 3 days ago, but I just learned about this mailing list and it seems more appropriate to ask this question here I guess. I already got a reply from Simon Marlow but I posted some further (so far unanswered) questions. The thread starts here: http://www.haskell.org//pipermail/haskell-cafe/2009-August/064880.html. Basically my remaining questions are: 1. How can one safely perform a blocking wait on a system call via FFI when compiling with -threaded and avoid signal interruptions which cause the call to return with EINTR? 2. Could 1. be achieved by blocking SIGVTALRM in the thread doing the call? For details please cf. the original maling list thread. Many thanks, Levi

3 5

Re: What is the mutator?
by Jost Berthold 14 Aug '09

14 Aug '09

> Message: 1 > Date: Thu, 6 Aug 2009 00:38:08 -0700 > From: Jason Dusek <jason.dusek(a)gmail.com> > Subject: What is the mutator? > To: glasgow-haskell-users(a)haskell.org > Message-ID: > <42784f260908060038h53d7cc0dy9f80e43f269a2faf(a)mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > I've been reading a little about GC latency and have run > across statements like this: > > One solution to the GC synchronisation problem would be to > implement a concurrent garbage collector. Typically, > however, concurrent GC adds some overhead to the mutator, > since it must synchronise with the collector.some thunks are > never “black-holed”, so giving a potential performance win. > Unfortunately, in the parallel setting, it substantially > enlarges the time window in which two or more duplicate > threads might evaluate the same think, and thus > > -- Comparing and Optimising Parallel Haskell Implementations > for Multicore Machines > > What is the mutator? Hi Jason, as Malcolm already said, the "mutator" in this text is the/a thread evaluating some Haskell expression. Just to add some more details to the picture... In general, a Haskell expression is a computation represented as a graph in the heap. Haskell evaluates lazily and does not have to fully evaluate every part of it for the program to finish. Unevaluated parts are "thunks". As soon as one of potentially several concurrent (mutator) threads starts to evaluate a thunk, it is replaced by a blackhole, which keeps other threads out of it until the node in the graph is evaluated (say, to a list cons (:), with probably unevaluated head and tail). Then the blackhole is updated with the new value. Other threads block on the blackhole in the meantime (so not necessarily an exception in the case of concurrent mutator threads) and are woken up by the update. The passage you quote above is about two separate aspects: 1. Garbage collection and mutator running concurrently: while they usually do, they do not _have_ to exclude each other, but not doing so means that the objects they are treating have to be locked. 2. About "Blackholing": in the sequential evaluation (where hitting a blackhole indeed means to have a loop), some better performance can be gained by not blackholing a thunk immediately, so this was done in GHC earlier. However, it increases the chance for 2 mutator threads to evaluate the same thunk (double work), and we got better performance by blackholing immediately. Cheers, Jost

4 4

Re: Haskell Platform 2009.2.0.2
by Christian Maeder 10 Aug '09

10 Aug '09

Don Stewart wrote: > Heads up lads, we're about 24 hours from Haskell Platform 2009.2.0.2 > > http://code.haskell.org/haskell-platform/haskell-platform.cabal I still see time ==1.1.2.4, although ghc-6.10.4 comes with: time-1.1.4 http://trac.haskell.org/haskell-platform/ticket/74 Is this on purpose (possibly installing two time versions)? I only know that time-1.1.4 and time-1.1.3 supply more Typeable instances (which may break existing code) Cheers Christian

2 1

use gtar and not tar under solaris
by Christian Maeder 10 Aug '09

10 Aug '09

Hi, I've just been informed that unpacking the binary (i386) solaris distribution using bunzip2 and tar: bunzip2 -c ghc-6.10.4-i386-unknown-solaris2.tar.bz2 | tar xvf - does not work properly! Use instead: gtar jxvf ghc-6.10.4-i386-unknown-solaris2.tar.bz2 File names longer than a hundred characters are cut off, i.e. ghc-6.10.4/libraries/dph/dph-prim-seq/dist/build/Data/Array/Parallel/Unlifted/Sequential/Flat/UArr.hi is wrongly extracted as: ghc-6.10.4/libraries/dph/dph-prim-seq/dist/build/Data/Array/Parallel/Unlifted/Sequential/Flat/UArr.h leading to an installation failure: installPackage: Error: Could not find module: Data.Array.Parallel.Unlifted.Sequential.Flat.UArr with any suffix: ["hi"] gmake[1]: *** [install.library.dph/dph-prim-seq] Error 1 Ian, could you place a note about using gtar for unpacking solaris binary-dists? Cheers Christian

4 10

gcc version for GHC 6.10.4 under Sparc/Solaris
by Christian Maeder 10 Aug '09

10 Aug '09

Hi Ian, could you add a note on the download page that GCC version 4.3.x is not suited for: http://www.haskell.org/ghc/dist/6.10.4/maeder/ghc-6.10.4-sparc-sun-solaris2… The binary-dist was compiled using gcc-4.2.2 (but also works i.e. for gcc-3.4.4) page http://hackage.haskell.org/trac/ghc/wiki/Building/Solaris says: "GCC version 4.1.2 is recommended" and "GHC has not yet been updated to understand the assembly output of GCC version 4.3.x." Maybe a ticket should be opened for gcc-4.3.x under Sparc/Solaris Did anyway use gcc-4.3.x under x86 Solaris? (I don't think, it'll have the same problem.) Cheers Christian

3 4