August 2013 - ghc-devs

GHC branch "atomics" pushed
by Ryan Newton 21 Aug '13

21 Aug '13

Hi all, There should be very little that is controversial about this branch because it adds primops upon which nothing else depends and which users will not see directly. But for now I've added it to a branch called "atomics" (likewise use the "atomics" testsuite branch of course). As soon as Carter and I work out a bit more of the future roadmap I'll merge it into master. Carter, would you like to use this branch to develop the improved LLVM support for the primops that are now added there? Cheers, -Ryan P.S. Carter, as you requested I'll add an extra trac ticket for discussion.

3 3

Instantiating a type with fresh, flexi type variables
by Dr. ERDI Gergo 20 Aug '13

20 Aug '13

For my pattern-synonyms branch (see prev. email) I had to write the following function, incl. making TcValidity.fvTypes public: tcInstTypes :: [TcType] -> TcM [TcType] tcInstTypes tys = do { let tvs = fvTypes tys ; (_, _, subst) <- tcInstTyVars tvs ; return $ map (substTy subst) tys } I'm surprised I had to write this myself, and this made me wonder if there's a much better way to handle cases where I have some kind of definition which has some inferred type, and then various use sites of that definition must all have types that can be unified with this original inferred type. Is there? Thanks, Gergo

3 3

DNS entry for git.haskell.org active now!
by Herbert Valerio Riedel 20 Aug '13

20 Aug '13

Hello GHC Devs, Hopefully, the new DNS entry for git.haskell.org should be visible for all of you by the time you read this. This mostly completes the migration part of the GitolitePlan[1]. With the new hostname, the URLs to use for `sync-all` to fetch via git://, http://, or ssh:// (ordered by increasing latency & url length) are ./sync-all -r git://git.haskell.org remote set-url origin ./sync-all -r http://git.haskell.org remote set-url origin ./sync-all -r ssh://git@git.haskell.org remote set-url origin ...and for setting the push-URL (via ssh://) use ./sync-all -r ssh://git@git.haskell.org remote set-url --push origin Please note that the (deprecated) `/libraries` symlink to `/packages` is only supported at the old http://darcs.haskell.org/ Git repo location. Finally, the new Gitweb interface[2] to the GHC Git repos should have become accessible for everyone (w/o hacking `/etc/hosts`). Cheers, hvr [1]: http://ghc.haskell.org/trac/ghc/wiki/GitolitePlan [2]: http://git.haskell.org/

3 5

Advice about TcDeriv
by Joachim Breitner 20 Aug '13

20 Aug '13

Hi, to support deriving NT instances properly, TcDeriv needs to be modified. But there are some structural obstacles: So far, all classes which had to be had the “type of interest” as their only type argument. Therefore, DerivSpec, the data structure in that file, carries information about what instances to derive, in the field dc_tc :: TyCon. But with NT it is different: * It has two parameters, * the type of interest is likely not the last parameter (e.g. NT Age Int) * and it can happen that there is a type variable in the last parameter (e.g. NT Int a => NT Age a). All that is difficult to squeeze into the existing data structure. The data type also has the ds_tys :: [Type] parameter, which contains all type parameters to the class (e.g. [Int, a]). So at first I thought about simply removing dc_tc and use the data from (last ds_tys) whenever needed. But in the case of type families, ds_tc is not just the type constructor of (last ds_tys), but rather what it resolves to. So before I rewrite lots of code there, I’d like to get some advice: Should I extend the DerivSpec to support multi-parameter-typeclasses (and figure out how to support data families here), or rather bypass the whole lot and handle NT instance generation separately? Or is there maybe another, more elegant way? Thanks, Joachim -- Joachim “nomeata” Breitner mail(a)joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata(a)joachim-breitner.de • GPG-Key: 0x4743206C Debian Developer: nomeata(a)debian.org

2 4

RE: lambda mining
by Simon Peyton-Jones 19 Aug '13

19 Aug '13

(devs: this thread is about adding useful new benchmarks to nofib.) Oh bother. I'd forgotten about dependencies. I don't want to make building nofib depend on libraries other those in GHC anyway (bytestring, unix ok, asynch perhaps not). If that makes it tricky, maybe we should give up on the idea. S From: José Pedro Magalhães [mailto:jose.pedro.magalhaes@cs.ox.ac.uk] Sent: 05 August 2013 08:41 To: Simon Peyton-Jones Subject: Re: lambda mining I'm not entirely sure how to do that, though. Do I just add it to the "real" subset? How about dependencies (e.g. bytestring >= 0.9, unix >= 2.5.0, async >= 2.0.0.0, ...) Cheers, Pedro On Fri, Aug 2, 2013 at 9:02 AM, Simon Peyton-Jones <simonpj(a)microsoft.com<mailto:simonpj@microsoft.com>> wrote: great! Just add it :-) simon From: José Pedro Magalhães [mailto:jpm@cs.ox.ac.uk<mailto:jpm@cs.ox.ac.uk>] Sent: 30 July 2013 07:48 To: Simon Peyton-Jones Cc: Nicolas Wu; Wouter Swierstra; Jeroen Bransen Subject: Re: lambda mining Hi Simon, (CC-ing co-authors) Yes, I think it might work fine. Its running time can also be adjusted easily, depending on the maps given as input and some internal parameters. How would we go about adding it to nofib? Thanks, Pedro On Tue, Jul 30, 2013 at 7:04 AM, Simon Peyton-Jones <simonpj(a)microsoft.com<mailto:simonpj@microsoft.com>> wrote: Pedro Wandering past your home page I took a look at your "lambda mining" paper. Would it be suitable as a nofib benchmark? Moderate size, authentic code... Would you be interested? Simon

3 4

Non-parallel version of GC
by Edward Z. Yang 19 Aug '13

19 Aug '13

Hello all, How would people feel about an alternate GC implementation in GHC which is not parallel? A GC like this would be simpler to understand, maybe a little faster when parallel collection is not being used, and (most importantly for my case) easier to extend with interesting features. In particular, this implementation would not have gen_workspace or gc_thread; these would either be unnecessary or folded directly into the actual generation object. Thanks, Edward

2 3

Literal overflow test fails
by Simon Peyton-Jones 19 Aug '13

19 Aug '13

On 32 bit Windows I get this (with HEAD). libraries\Win32\Graphics\Win32\GDI\HDC.hs:145:14: Warning: Literal 2147483648 of type Int overflows The offending code is: setTextCharacterExtra dc extra = failIf (== 0x80000000) "SetTextCharacterExtra" $ c_SetTextCharacterExtra dc extra The new literal-overflow test objects to 0x80000000 :: Int. I'm not sure if it should object; in this case we are deliberately using the bit-pattern for minBound. Also what happens on a 64-bit architecture? What should the behaviour here be? - should we use minBound here? - what should the new literal-overlflow code do for 0xblah constants? This is currently breaking the HEAD build. Simon

4 4

Wired-in type class
by Joachim Breitner 19 Aug '13

19 Aug '13

Dear List, I have some questions about the inner parts of GHC, where I need to learn a lot. This is related to my attempts on newtype casting, but should probably be kept separate from the conceptual discussions. Say I need to create a wired-in type class, because it cannot be represented in Haskell. The Core type constructor that will come out of it will have one field of type ~R#, which is the reason why I cannot write it in Haskell. It seems that defining something wired-in is not a very local operation that affects, at least primops.txt.pp and TysPrim.lhs. Does it affect more? It seems that there is not precedent of a wired-in type class. Is that possible without touching too many parts of the compiler? Or is it saner to just have "class NT a b" in a module in ghc-prim without the constraint and use special magic when compiling that file to add the required field to the data constructor representing the class? (Similar to how the kind of ~ is adjusted during compilation?) Greetings, Joachim -- Joachim “nomeata” Breitner mail(a)joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata(a)joachim-breitner.de • GPG-Key: 0x4743206C Debian Developer: nomeata(a)debian.org

4 7

RE: [GHC] #7901: Bad error message when using UnicodeSyntax ∀ without ExplicitForall
by Simon Peyton-Jones 19 Aug '13

19 Aug '13

Don't forget to update the "Test case" field of the ticket. Generally we name the test cases the same as the ticket (eg T7901 in this case), but the test case field * is a quick check that there IS a regression test * works even if the test is named differently (in this case ParserNoForallUnicode) * works if there are multiple tests * tells which directory to look in (in this case parser/should_fail) I've updated http://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/BugTracker to add these comments Simon | -----Original Message----- | From: ghc-tickets [mailto:ghc-tickets-bounces@haskell.org] On Behalf Of | GHC | Sent: 19 August 2013 05:17 | Cc: ghc-tickets(a)haskell.org | Subject: Re: [GHC] #7901: Bad error message when using UnicodeSyntax ∀ | without ExplicitForall | | #7901: Bad error message when using UnicodeSyntax ∀ without | ExplicitForall | -------------------------------------------------+---------------------- | --- | Reporter: exbb2 | Owner: | ajp | Type: bug | Status: | patch | Priority: normal | Milestone: | Component: Compiler | Version: | 7.6.2 | Resolution: | Keywords: | Operating System: Unknown/Multiple | Architecture: | Type of failure: Incorrect warning at | Unknown/Multiple | compile-time | Difficulty: | Test Case: | Unknown | Blocking: | Blocked By: | | Related Tickets: | -------------------------------------------------+---------------------- | --- | | Comment (by Austin Seipp <aseipp@…>): | | In [changeset:5535416500167a1167bf8b375acf999ad4b20924/testsuite]: | {{{ | #!CommitTicketReference repository="testsuite" | revision="5535416500167a1167bf8b375acf999ad4b20924" | Test case for #7901. | | Signed-off-by: Austin Seipp <aseipp(a)pobox.com> | }}} | | -- | Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7901#comment:7> | GHC <http://www.haskell.org/ghc/> | The Glasgow Haskell Compiler | | _______________________________________________ | ghc-tickets mailing list | ghc-tickets(a)haskell.org | http://www.haskell.org/mailman/listinfo/ghc-tickets

1 0

Question about `compileToCoreModule`
by Daniel F 19 Aug '13

19 Aug '13

Hi, everyone, I have a question about `compileToCoreModule` function from the GHC module. I noticed that the following code not just outputs the Core code, but also produces object files and a linked executable (in case when 'test.hs' is a program): --------------------------- module Main where import DynFlags import GHC import GHC.Paths import MonadUtils import Outputable main = defaultErrorHandler defaultFatalMessager defaultFlushOut $ do runGhc (Just libdir) $ do dflags <- getSessionDynFlags setSessionDynFlags dflags cm <- compileToCoreModule "test.hs" output cm -- | Outputs any value that can be pretty-printed using the default style output :: (GhcMonad m, MonadIO m) => Outputable a => a -> m () output a = do dfs <- getSessionDynFlags let style = defaultUserStyle let cntx = initSDocContext dfs style liftIO $ print $ runSDoc (ppr a) cntx ----------------------------- I thought this was strange and looked up the source of 'compileToCoreModule', and indeed, it calls 'load LoadAllTargets'. So my question is, why is it necessary to do so? I had the impression that compiling Haskell to Core is a step that precedes compiling to the actual binary. NB: I tried setting `ghcLink' and `hscTarget' options in dynflags to `NoLink' and `HscNothing' respectively, but that resulted in somewhat weird Core: $ cat test.hs module Test (test) where test :: Int test = 123 test2 :: String test2 = "Hi" $ ./testcore %module main:Test (Safe-Inferred) [(reF, Identifier `Test.test')] Test.test :: GHC.Types.Int [LclIdX] Test.test = GHC.Types.I# 123 $ ./testcore-nolinknothing %module main:Test (Safe-Inferred) [] Thanks. -- Sincerely yours, -- Daniil Frumin

1 0