October 2014 - ghc-devs

dropWhileEndLE breakage
by Simon Peyton Jones 02 Oct '14

02 Oct '14

What's going on here? No other library module defines this function, except in Cabal! Simon libraries\base\GHC\Windows.hs:124:16: Not in scope: 'dropWhileEndLE' Perhaps you meant 'dropWhileEnd' (imported from Data.OldList) libraries/base/ghc.mk:4: recipe for target 'libraries/base/dist-install/build/GHC/Windows.o' failed

2 1

Feedback request for #9628 AST Annotations
by Alan & Kim Zimmerman 02 Oct '14

02 Oct '14

Hi All I am looking for some input on #9628 for source annotations. The intent behind this is to make it easier for tool developers to add extra information to the AST. This is to assist in structured editing or other source to source conversions, such as refactoring. One of the use cases would be to maintain the ParsedSource as tightly coupled to the editor, where changes would be made directly to the AST and only indirectly to the text source. This is the approach enabled by structured haskell mode, or demonstrated in lamdu. Ideally it should be possible to perform a change to the ParsedSource, and then submit it to the renamer and typechecker for error and warning feedback. As such the renamer / typechecker should be able to accept the annotated AST. Eventually this process should be incremental, since a given edit takes place in a structured way in a single position at a time, so it should be possible to identify which part of previously done work is invalidated by it and needs to be redone. This would happen in the context of a ghci session operating as a server. In order to lay the initial groundwork for this, I have updated the AST in hsSyn to replace all of the `Located` elements with `GenLocated l`, where `l` is constrained to be a member of class `ApiAnnotation`. class (Ord l, Outputable l, OutputableBndr l) => ApiAnnotation l where annGetSpan :: l -> SrcSpan annSetSpan :: l -> SrcSpan -> l annNoSpan :: l This guarantees that the annotation does in fact keep a `SrcSpan` in it. I have also worked this through the renamer, typechecker, and desugarer, and the monad for core. I have kept the `Located` / `GenLocated SrcSpan` boundary for the parser, and within the `RdrName`,`Name`,`Id` types. In this context the hooks become especially important, but they need to get the annotation type parameter. It seemed extreme to force the `DynamicFlags` to have to have the type parameter, so I am proposing to move the hooks to `HscEnv`, which needs a type parameter, even as a phantom type, to make sure that the right data structures are instantiated in the monads for the various passes. This is a big change, and I am very much working in the dark, so I would love some feedback or discussion. 1. Is this change too big, should I scale it back to just update the HsSyn structures and then lock it down to Located SrcSpan for all the rest? 2. Will the ApiAnnotation constraint and resolution cause performance degradation? 2. Is it ok to move the hooks into HscEnv? 3. In order to have a single session for a project, it needs a single annotation parameter. To support this the parser needs to produce annotated output. It should be a simple case of updating the L0/L1/LL macros and production types. Does it make sense to do this? This is intended to be an enabling change, without changing the structure of any code or the AST. A later change would introduce additional annotations in HsSyn to track the locations of the various keywords and other punctuation so that exactly regenerating source is much easier, without requiring extensive examiniation of the tokens. References 1. https://ghc.haskell.org/trac/ghc/ticket/9628 2. https://ghc.haskell.org/trac/ghc/wiki/GhcAstAnnotations 3. https://phabricator.haskell.org/D246 4. https://github.com/alanz/ghc/commits/wip/ast-ann-location Regards Alan

5 18

sync-all
by Simon Peyton Jones 02 Oct '14

02 Oct '14

Herbert says (in bold font) "do not ever use sync-all", in this post http://www.reddit.com/r/haskell/comments/2hes8m/the_ghc_source_code_contain…. If that's really true, we should either nuke it altogether, or change it to do something correct. The idea that it might "set up your tree in subtly different ways" is alarming. Simon

5 5

Re: Build time regressions
by Edward Z. Yang 02 Oct '14

02 Oct '14

Hello Joachim, This was halfway known, but it sounds like we haven't solved it completely. The beginning of the sordid tale was when Cabal HEAD switched to using derived binary instances: https://ghc.haskell.org/trac/ghc/ticket/9583 SPJ fixed the infinite loop bug in the simplifier, but apparently the deriving binary generates a lot of code, meaning a lot of memory. https://ghc.haskell.org/trac/ghc/ticket/9630 hvr's fix was specifically to solve this problem. But it sounds like it didn't eliminate the regression entirely? If there's an unrelated regression, we should suss it out. It would be helpful if someone could revert just the deriving changes, and see if this reverts the compilation time. Edward Excerpts from Joachim Breitner's message of 2014-09-30 13:36:27 -0700: > Hi, > > the attached graph shows a noticable increase in build time caused by > > Update Cabal submodule & ghc-pkg to use new module re-export types > author Edward Z. Yang <ezyang(a)cs.stanford.edu> > https://git.haskell.org/ghc.git/commit/4b648be19c75e6c6a8e6f9f93fa12c7a4176… > > and only halfway mitigated by > > Update `binary` submodule in an attempt to address #9630 > author Herbert Valerio Riedel <hvr(a)gnu.org> > https://git.haskell.org/ghc.git/commit/3ecca02516af5de803e4ff667c8c969c5bff… > > > I am not sure if the improvement is related to the regression, but in > any case: Edward, was such an increase expected by you? If not, can you > explain it? Can it be avoided? > > Or maybe Cabal just became much larger... +38% in allocations when > running haddock on it seems to confirm this. > > Greetings, > Joachim >

4 4

The future of the haskell2010/haskell98 packages - AKA Trac #9590
by Austin Seipp 01 Oct '14

01 Oct '14

Hello developers, users, friends, I'd like you all to weigh in on something - a GHC bug report, that has happened as a result of making Applicative a superclass of Monad: https://ghc.haskell.org/trac/ghc/ticket/9590 The very condensed version is this: because haskell2010/haskell98 packages try to be fairly strictly conforming, they do not have modules like Control.Applicative. Unfortunately, due to the way these packages are structured, many things are simply re-exported from base, like `Monad`. But `Applicative` is not, and cannot be imported if you use -XHaskell2010 and the haskell2010 package. The net result here is that haskell98/haskell2010 are hopelessly broken in the current state: it's impossible to define an instance of `Monad`, because you cannot define an instance of `Applicative`, because you can't import it in the first place! This leaves us in quite a pickle. So I ask: Friends, what do you think we should do? I am particularly interested in users/developers of current Haskell2010 packages - not just code that may *be* standard Haskell - code that implies a dependency on it. There was a short discussion between me and Simon Marlow about this in the morning, and again on IRC this morning between me, Duncan, Edward K, and Herbert. Basically, I only see one of two options: - We could make GHC support both: a version of `Monad` without `Applicative`, and one with it. This creates some complication in the desugarer, where GHC takes care of `do` syntax (and thus needs to be aware of `Monad`'s definition and location). But it is, perhaps, quite doable. - We change both packages to export `Applicative` and follow the API changes in `base` accordingly. Note that #1 above is contingent on three things: 1) There is interest in this actually happening, and these separate APIs being supported. If there is not significant interest in maintaining this, it's unclear if we should go for it. 2) It's not overly monstrously complex (I don't think it necessarily will be, but it might be.) 3) You can't like `haskell2010` packages and `base` packages together in the general case, but, AFAIK, this wasn't the case before either. I'd really appreciate your thoughts. This must be sorted out for 7.10 somehow; the current situation is hopelessly busted. -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

3 3

Using cabal-install with GHC HEAD?
by Stephen Paul Weber 01 Oct '14

01 Oct '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 I'm running cabal-install 1.20.0.3 -- when I try to install packages for my cross-compiler built from GHC HEAD I get: > ghc-stage1: ghc no longer supports single-file style package databases > (dist/package.conf.inplace) use 'ghc-pkg init' to create > the database with the correct format. So, do I need an even newer version of cabal-install (HEAD maybe?)? Or does cabal-install just not support GHC HEAD yet at all yet? - -- Stephen Paul Weber, @singpolyma See <http://singpolyma.net> for how I prefer to be contacted edition right joseph -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBCAAGBQJULCK/AAoJENEcKRHOUZzeoigP/0ScPQUxO4lPp7zr2yNz/Vvu fXAyAnEfKssFvCgnXNvaRhj4mGvIb+aRMDT5xs2bCMkx2ZJr1jWOVJrRX1wYmI5M PM6pMQYxJxr4avhPNra388lkkYLf/A7OA/dXvv3Z93TpPWJ6wTwNf0kmnysWo5/j ZLD8qKAMgFjrw6j55gM/gyb9eYKA5eMssVBvlK9YWrHR1InoVmP+Ua+ru50ClP2b WTbH8GFSKcijli1EKPzYzGAvmwcEGTmua+DEo6BvBAciaqDrd1a0FbxYze3IkLq9 frb4PuK71ehd+uQgGrRMqaS+Zty1Rj7lV1NBhHKiL/eT5WBNXuotfDgp9/GT+ch6 ULg3JSTTJ3KEJJ87vmGwgt92RXcJhLHSzWl+3gY10wFvSCt0mHQwFuo+u7nQ+yuG PRBKMN7osnPJR1DjSzIYcGBgSPhMFdBUouiVUiiacEoZF8ukdSO2xXoOB6z3OihB XDVv5tqvp2dbDzHTyJQWl0O381JiDC6Lwogb0Q+G6+rA3CAkh2D+8ryda/zWTze2 DCuu40+MQa6YjO5rXn+eQtXaXVXZUBY1P8VFE7oRfkgxjA78ahT46rpNgtzwlNp0 bPEnBh6lVq3eGwuv/dqtonASOZp3/MEaySBdi6ZCokbZhKagLEY660eHFHY6aURu 6gT+FZFLIOzzl+Xhka/T =A0vd -----END PGP SIGNATURE-----

2 1

Is there a way to add a dynamic library to every link with GHC automatically?
by Stephen Paul Weber 01 Oct '14

01 Oct '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 I'm working with my qnx-nto-arm cross-compiler again. I still have the issue where I get link errors about __aeabi_memcpy and similar. I am able to solve this problem by always adding -lcaps to ghc invocations. I'm still not sure if that library should be required, but it does fix the problem. So now I'm wondering if there's a way to tell my GHC build that when it is built for this platform it should just always link against libcaps as well as whatever else? - -- Stephen Paul Weber, @singpolyma See <http://singpolyma.net> for how I prefer to be contacted edition right joseph -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBCAAGBQJUK06LAAoJENEcKRHOUZzekNYQAMMVMpXE1hG0UxFDvKcDzBrD xbK5woDC/7LRhGsXNntG7PM76/vaL51KYenCrPuejYD3xAJXVZY9FifR6yx77qQg ysqX3IZzOQXxAiGDXkkYdf/G2NRIBKhCyCZacY4eCOfRSLVLO58bNbsZI96enrSN j4BTtWoeM/l2wGavV+5QtkDYXrPF7Lg16q1A4w3a7wPLH3YLqeql81gG1qdi55sc nVegs1+Bnr3AzqaMr5n0p5hX0Q+OklNUGVEPRtX6Dh8q7z5MmjKgswXZbukzFUEU wxCSmZYmuQXjYCa0aJkW5J8/2BYBNAkHwTZzZ2GyCtcigCaeaXGppBfEdHk5FHT1 YbyiAheOBJ2ZsTIYdIJEwCGT8KHlxQvruWX3y03LDzV62CX5aMqlISY7oSGY9WM6 ZclMP0mM7whScCdpX2yDsJQV2orSEaWd/9nCF+yVSq4SNpC3fQSzR/aT5PlEpdLh dSnPvPfrDOPdWKF3mITj4P2/oDBO8+iWd6vIUWXjyHrG/iZS5tfeuN9yD8SSudFI l9jiOTPOvOZSyVCXaVEJ0nheUteCM5yAXFN9ipQAuLA10QpH2vt/QpcJ8bvuaMN3 tS+SHr31zV29OZ5nnTaz+Cn8kXaMSSHlgyK/zUjhs2KJAw4XakdzayYS+aLV1Zpz kcs3y8hA/EMu2lTDKYC3 =yv6N -----END PGP SIGNATURE-----

1 1

RE: mkCoreConApps vs. mkConApp
by Simon Peyton Jones 01 Oct '14

01 Oct '14

mkConApp assumes the let/app invariant holds, and hence does not need to carry around, decompose, or test the function type. Hence slightly more efficient. My instinct is to make mkConApp have ASSERT checks for the let/app invariant (and indeed the function having enough (->) arrows), but under #ifdef DEBUG. And rename it "mkLazyConApp" to stress that there's an invariant involved. In contrast mkCoreConApp must carry round the types in order to generate a Case sometimes. Do you feel like doing that? (In HEAD.) Or shall I? Simon | -----Original Message----- | From: Richard Eisenberg [mailto:eir@cis.upenn.edu] | Sent: 29 September 2014 20:05 | To: Simon Peyton Jones | Subject: mkCoreConApps vs. mkConApp | | Hi Simon, | | I ran into a core-lint error on my branch which led me to wonder: when | should anyone use CoreSyn.mkConApp instead of MkCore.mkCoreConApps? | They appear to do roughly the same thing, but mkCoreConApps does more | checks (specifically, in my case, the let/app invariant check) and | claims to be more efficient. mkConApp even tells you to use | mkCoreConApps "if possible". When isn't this possible? | | To fix my error, I changed all uses of mkConApp in MkCore to | mkCoreConApps. Problem solved. But it's all a bit of a mystery why the | problem was there to begin with. Can you shed any light? | | Thanks! | Richard | | PS: The reason this happened on my branch is because of different | handling of making unboxed tuples, thanks to levity-polymorphism.

1 0

GHC Weekly news
by Austin Seipp 01 Oct '14

01 Oct '14

Hi *, Here's the latest weekly news post: https://ghc.haskell.org/trac/ghc/blog/weekly20140930 Included verbatim for those too lazy to open new tabs: ---------------- Hi *, Here's some news for y'all! Apologizes about the unavailability last week; the internet wasn't exactly a very fun place for a system administrator... So without delay, here's the current recap of the past two weeks: - Lots of merged code and code reviews have gone in, and a lot of commits: in the past two weeks since the last update, `ghc.git` has seen just over 100 commits, from about a dozen different developers. - As part of those patches, a significant amount of them have gone towards implementing the "Burning Bridges Proposal" or BBP for the `base` library. This is a set of changes to `base` that have generalized many parts of the API, by putting `Traversable` and `Foldable` in the Prelude. This required a bit of shoveling by Herbert, but now this is all now in GHC HEAD, and will be part of 7.10: - `Prelude` combinators, like `mapM`, have been generalized to the `Traversable` and `Foldable` classes. - Several other modules, like `Control.Monad` and `Data.List`, have been generalized to `Traversable` and `Foldable` where applicable. - `Control.Monad` combinators generalized to `Applicative` where possible. - Similarly, `MonadPlus` combinators like `guard` are generalized to `Alternative`. - `Foldable` has been extended with new methods, like `length` and `null`. - But also, GHC's compiler is now tab-free! That's right, after what seemed like a million years, a very large portion of the code has been detabbed, and `-fwarn-tabs` is now on by default in the GHC build. - There are an assortment of other changes: GHC's linker is not as loud[1], and various documentation improvements. - The windows build is broken *again* unfortunately, this time due to what seems to be a Cabal update, I think. Austin is once again on the case. - The HCAR draft for October has seen some nice improvements. If you're a developer, please amend things. If you're a user, read with eager anticipation of all the new features![2] - It turns out the new Applicative/Monad changes have unfortunately broken the `haskell98` and `haskell2010` packages, with an unclear migration strategy for the future: see #9590. For GHC 7.10, it seems the `haskell2010` packages will need to change to accomodate these standard deviations. If any users of the `haskell98` or `haskell2010` packages would speak up to help, that would be fantastic. The discussion will surely continue for a little bit - 7.10 is still a ways off. In miscellaneous news: - ghc.haskell.org may have been temporarily unavailable during this weekend due to an emergency downtime with our provider for a security update, but the window was quite small. - Relatedly (but not the exact same scenario), the internet also caught fire in several other places, requiring quite a lot of careful watching and remediation after the Bash "ShellShock" bug hit last week. And I think that sums it up quite nicely, folks! Closed tickets for the past two weeks include (there are a lot of them!): #9650, #7068, #5190, #5880, #8374, #9603, #3303, #3470, #3509, #781, #8115, #9641, #9191, #9515, #9326, #7987, #9634, #9576, #9612, #9635, #8593, #7544, #8529, #9338, #5794, #9535, #3646, #617, #8026, #8480, #8881, #9366, #8251, #7673, #8983, #8369, #8897, #8070, #9550, #9057, #9629, #8836, #8960, #8941, #9565, #9589, #5248, #8918, #9568, #9620, #1042, #9557, #7863, #5647, #9610, #5395, #9580, #9529, #4426, #9607, #9592, #8097, #9559, #9560, #4218, #9602, #9528, #9530, #9423, #9400, #1407, #9598, #9597. I'd like to mention that for the above tickets, a *huge* amount of them were closed by one of our newest contributors, **Thomas Miedema**, who went through the bug tracker and confirmed or closed a large majority of them. I lost track of how many. Thanks Thomas! [1] https://github.com/ghc/ghc/commit/9f7e3633c692dce75c27607131bd386178fb0fcf [2] https://ghc.haskell.org/trac/ghc/wiki/Status/Oct14 -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

2 1