- ghc-devs - Haskell.org

Tooling-friendly ModSummary
by Alan & Kim Zimmerman 05 Sep '16

05 Sep '16

At the moment the standard way to use the GHC API is something like _ <- load LoadAllTargets modSum <- getModSummary mn p <- parseModule modSum And likewise if renamed or typechecked ASTs are needed. But the `load` step already does all those phases. So, would there be any objection to modifying the ModSummary to possibly retain those artifacts, configurable via a DynFlag? I would expect the flag would default to retaining none, but could then either provide for returning all artifacts, or just for the targets explicitly listed in the `setTargets` call (i.e. not the full `depanal` result). Regards Alan

2 2

cabal
by Simon Peyton Jones 05 Sep '16

05 Sep '16

I’m trying to follow the instructions for https://ghc.haskell.org/trac/ghc/ticket/12562 But I get cabal new-build llvm-general --with-ghc=/home/simonpj/5builds/HEAD-4/inplace/bin/ghc-stage2 cabal: unrecognised command: new-build (try --help) simonpj@cam-05-unx:~/tmp/llvm-general$ Maybe my Cabal is too old. I tried bash$ cabal install Cabal Resolving dependencies... Downloading Cabal-1.24.0.0... Configuring Cabal-1.24.0.0... Building Cabal-1.24.0.0... Installed Cabal-1.24.0.0 That worked. But I get the same message. Alas bash$ cabal --version cabal-install version 1.23.0.0 compiled using version 1.23.1.0 of the Cabal library bash$ which cabal /home/simonpj/.cabal/bin/cabal Maybe I need 1.24. Which claims to be installed. But WHERE is it installed? Thanks Simon

3 3

Call for Nominations: GHC Steering Committee
by Ben Gamari 05 Sep '16

05 Sep '16

Hello everyone, As you likely know, over the last few months we have been discussing options for reforming the process for proposing language and compiler changes to GHC. After much discussion, we have a process [1] which, while not perfect, is acceptable to a majority of our contributor base and will be an improvement over the status quo. While we invite suggestions for future improvements, we are at a point where we can move ahead with implementation. Consequently, we are seeking nominations for the initial GHC steering committee. This body is responsible for overseeing the progression of proposals through the process, working with authors on refining their ideas, and evaluating proposals for acceptance. The committee will consist of five to eight members of diverse backgrounds. We would like to offer the following as a criteria for membership. Note that a candidate is not expected to satisfy all or even most of these criteria, but a good candidate should satisfy at least one: * A history of contributions to the design of new language features * Experience developing Haskell libraries and applications * A demonstrated track record of contributing code to GHC * A pedagogical background, with experience in either teaching or authoring educational materials * Experience in compiler development * Knowledge of functional programming language theory I'd like to emphasize that committee membership is as much a duty as it is a privilege. Membership is not intended to be a platform to be used by members to drive their own ideas; rather it is a way of serving the Haskell community by helping other community members refine and advance their proposals. This, of course, requires an investment of time and effort, which you should be willing and able to consistently put forth. If you'd like to be considered for committee membership then please write a statement describing why you feel you are well-qualified to serve, in terms of the criteria above and any others that you would like to offer. Please send your statements to ben(a)well-typed.com by September 30th. The initial committee selection will be made by the Simons soon thereafter. Thanks to everyone for their feedback and cooperation so far! Cheers, - Ben [1] http://github.com/ghc-proposals/ghc-proposals

1 0

RE: Increasing version number of hsc2hs etc.
by Richard Cook 04 Sep '16

04 Sep '16

Perfect! Thanks for taking care of this. -RichardFrom: Ben Gamari Sent: ‎9/‎4/‎2016 6:32 AM To: rcook(a)rcook.org; ghc-devs(a)haskell.org Subject: Re: Increasing version number of hsc2hs etc. Richard Cook <rcook(a)rcook.org> writes: > Hi, > > I recently fixed a bug in hsc2hs which was merged into ghc-8.0. What's the > process around bumping the version number of hsc2hs and publishing a new > version of this package to Hackage? > Richard, for the record Herbert said he would prefer to wait until we are closer to the 8.0.2 release until we push the new release. I've opened GHC Trac #12568 to ensure that we don't lose track of this. Cheers, - Ben

1 0

Increasing version number of hsc2hs etc.
by Richard Cook 04 Sep '16

04 Sep '16

Hi, I recently fixed a bug in hsc2hs which was merged into ghc-8.0. What's the process around bumping the version number of hsc2hs and publishing a new version of this package to Hackage? -Richard

2 2

Unprincipled defaults
by David Feuer 02 Sep '16

02 Sep '16

On occasion, it can be useful to have default definitions that don't typecheck even with DefaultSignatures. It would be nice to be able to use them anyway. For example, if we have class Semigroup1 f where op :: f a -> f a -> f a then we could, hypothetically, give a default definition for (<>): default (<>) :: Semigroup1 f => f a -> f a -> f a (<>) = op But we can't give a default definition op = (<>) because there's no way to write its signature. However, for any F with instance Semigroup (F a) where ... the definition op = (<>) is perfectly fine. Would it be possible to offer a completely wild defaulting mechanism allowing *any expression* as a default, and only checking its type and compiling it when it's actually used?

2 2

Build GHC on Windows using Hadrian and Stack
by Andrey Mokhov 02 Sep '16

02 Sep '16

Hi all, Summary: Building GHC on Windows using Hadrian and Stack got even simpler - see https://github.com/snowleopard/hadrian/blob/master/doc/windows.md. To build GHC on Windows you usually need to jump through a lot of hoops [1], which may be confusing even for experienced GHC developers [2]. Hadrian to the rescue! Hadrian, a new build system for GHC that I've been developing [3], is written in Haskell and can therefore be built and run via Stack that can install appropriate bootstrapping GHC and MSYS2 environment in an automated and robust way. This was first pointed out by Neil Mitchell [4], and I've recently simplified build instructions even further. Here are all the steps: git clone --recursive git://git.haskell.org/ghc.git cd ghc git clone git://github.com/snowleopard/hadrian cd hadrian stack setup stack exec -- pacman -S autoconf automake-wrapper make patch tar --noconfirm stack build stack exec hadrian -- --directory ".." -j --flavour=quickest See more details here: https://github.com/snowleopard/hadrian/blob/master/doc/windows.md. NB: Hadrian can build Stage2 GHC, but there are still many limitations [5]. Help make it better! [1] https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows [2] https://mail.haskell.org/pipermail/ghc-devs/2016-June/012340.html [3] https://github.com/snowleopard/hadrian [4] http://neilmitchell.blogspot.co.uk/2016/03/compiling-ghc-on-windows.html [5] https://github.com/snowleopard/hadrian#current-limitations Cheers, Andrey

2 1

Phabricator diffs not viewable by non-logged in users
by Edward Z. Yang 01 Sep '16

01 Sep '16

For example, if I am not logged in (try an incognito/private browsing session), https://phabricator.haskell.org/D2501 reports an error. Is this intentional? Seems poor, and also the diff is labeled as Public in the UI. I found this quite surprising. Edward

3 2

Last call for merge requests for 8.0.2
by Ben Gamari 01 Sep '16

01 Sep '16

tl;dr. GHC 8.0.2 is coming. If you have a fix which you'd like to see merged into 8.0.2 and isn't already present in the tree, please speak up! Hello everyone, Over the last week I have been working down the (rather long) merge queue for the ghc-8.0 branch in preparation for a 8.0.2 release. At this point I think have merged nearly everything which will likely make it in to 8.0.2. If you have a patch which hasn't made it to the ghc-8.0 branch that you would like to see merged, please raise your concern on the appropriate Trac ticket. Thanks! - Ben

5 7

hsc2hs fix
by Richard Cook 31 Aug '16

31 Aug '16

Ben et al, I'm responding to your last call for merge requests ( https://mail.haskell.org/pipermail/ghc-devs/2016-August/012693.html) I would really like to get this fix to hsc2hs in if it all possible: https://phabricator.haskell.org/D2478 Thanks, Richard.

2 1