- ghc-devs - Haskell.org

Re: Stepping through ghc
by Omar Mefire 07 Oct '14

07 Oct '14

Hi Arash, Thanks for your reply. I'm interested in stepping through the compiler part (Lexer, Parser, etc...) of GHC for now. Thanks for the link to the commentary. I'm going through it right now. ------- "Hi Omar, You might want to narrow your scope to one part of GHC. For example, I mostly focused on the Run Time System to be able to conduct my master's thesis. Also, you might want to start off with a tiny goal, like to fix bug XYZ. Oh, and most important of all is the Commentary, which I think of as a wiki for GHC developers. http://ghc.haskell.org/trac/ghc/wiki/Commentary Cheers, Arash" Omar Mefire, Le Mardi 7 octobre 2014 0h08, Omar Mefire <omefire(a)yahoo.fr> a écrit : Hi Arash, Thanks for your reply. I'm interested in stepping through the compiler part (Lexer, Parser, etc...) of GHC for a beginning. Thanks for the link to the commentary. I'm going through it right now. P.S: I emailed you directly because I had some difficulties figuring out how to respond only to your message instead of the whole daily digest. Hopefully, will figure it out shortly. :) " Hi Omar, You might want to narrow your scope to one part of GHC. For example, I mostly focused on the Run Time System to be able to conduct my master's thesis. Also, you might want to start off with a tiny goal, like to fix bug XYZ. Oh, and most important of all is the Commentary, which I think of as a wiki for GHC developers. http://ghc.haskell.org/trac/ghc/wiki/Commentary" Omar Mefire, Le Lundi 6 octobre 2014 12h55, "ghc-devs-request(a)haskell.org" <ghc-devs-request(a)haskell.org> a écrit : Send ghc-devs mailing list submissions to ghc-devs(a)haskell.org To subscribe or unsubscribe via the World Wide Web, visit http://www.haskell.org/mailman/listinfo/ghc-devs or, via email, send a message with subject or body 'help' to ghc-devs-request(a)haskell.org You can reach the person managing the list at ghc-devs-owner(a)haskell.org When replying, please edit your Subject line so it is more specific than "Re: Contents of ghc-devs digest..." Today's Topics: 1. Re: GitHub pull requests (Richard Eisenberg) 2. RE: Show instance for SrcSpan (Simon Peyton Jones) 3. Re: GitHub pull requests (Ben Gamari) 4. Re: Stepping through ghc (Arash Rouhani) 5. RE: Again: Uniques in GHC (p.k.f.holzenspies(a)utwente.nl) ---------------------------------------------------------------------- Message: 1 Date: Mon, 6 Oct 2014 10:32:23 -0400 From: Richard Eisenberg <eir(a)cis.upenn.edu> To: andreas.abel(a)gu.se Cc: "ghc-devs(a)haskell.org Devs" <ghc-devs(a)haskell.org> Subject: Re: GitHub pull requests Message-ID: <DB3A2790-D285-4DE1-B05A-AF6F68389B88(a)cis.upenn.edu> Content-Type: text/plain; charset=us-ascii I think the "arc" barrier is significant. Personally, while I feel quite comfortable hacking on Haskell code, system tools are always a bit of a mystery. Those of you who help manage the infrastructure may feel like the tools are easy enough to pick up, but I'm sure there are many competent Haskell programmers out there who dread learning new tooling. (Perhaps I'm a representative sample of this set. I still say `git help merge` before just about every merge, just to make sure that I'm remembering the concepts correctly.) I absolutely believe that we should use the best tools available and that committed GHC contributors should have to learn these tools as necessary. Though I've had my problems with Phab and `arc`, I'm confident that this tool was chosen after a deliberative process and am grateful that we have leaders in this area in our midst. All that said, I think that the suggestion just to accept GitHub pull requests will lead to confusion, if only for the namespace problem. If we start to accept pull requests, then we are de facto going to have to deal with both the GH issue tracker and Trac's (and Phab's), and that is a terrible place to be. Part of the automated response to pull request submissions could be a post on the GH pull request record pointing folks to the Phab review that was created in response. The pull request would then be closed. I agree with the comment that users will be more committed to learn Phab once they have contributed. That's why I wanted to point them to Phab in the automated response to the GH pull request. I think there's a psychological commitment made by a person once they click "submit pull request" and they will be happy enough to follow up on Phab, especially if commenting and such doesn't require the installation of a local tool. Richard ------------------------------ Message: 2 Date: Mon, 6 Oct 2014 18:10:37 +0000 From: Simon Peyton Jones <simonpj(a)microsoft.com> To: Alan & Kim Zimmerman <alan.zimm(a)gmail.com>, "ghc-devs(a)haskell.org" <ghc-devs(a)haskell.org> Subject: RE: Show instance for SrcSpan Message-ID: <618BE556AADD624C9C918AA5D5911BEF3F319EA3(a)DB3PRD3001MB020.064d.mgd.msft.net> Content-Type: text/plain; charset="utf-8" By all means do so S From: ghc-devs [mailto:ghc-devs-bounces@haskell.org] On Behalf Of Alan & Kim Zimmerman Sent: 06 October 2014 13:59 To: ghc-devs(a)haskell.org Subject: Show instance for SrcSpan Is there any reason I can't put in a diff request to replace the derived Show instance for SrcSpan with a handcrafted one that does not exhausively list the constructors, making it more readable? Alan

1 0

Show instance for SrcSpan
by Alan & Kim Zimmerman 06 Oct '14

06 Oct '14

Is there any reason I can't put in a diff request to replace the derived Show instance for SrcSpan with a handcrafted one that does not exhausively list the constructors, making it more readable? Alan

6 9

Re: GitHub pull requests
by Herbert Valerio Riedel 05 Oct '14

05 Oct '14

Hello, On 2014-10-05 at 14:03:41 +0200, Joachim Breitner wrote: > Am Sonntag, den 05.10.2014, 13:08 +0200 schrieb Herbert Valerio Riedel: >> On 2014-10-05 at 12:56:28 +0200, Joachim Breitner wrote: >> >> [...] >> >> > I think the advantage could outweigh the downside and it’s worth a try. >> > We don’t even have to advocate it aggressively, just remove the „Do not >> > submit PRs“ notice on the repo and see what happens. >> > >> > (The problem with the ticket numbers remain, unfortunately.) >> >> Take into account though, there's no easy going back once we open that >> Pandora box; once GitHub allocates a #-number for a repo, it can only be >> removed by involving the GitHub admins, and until then any overlapping >> #-reference will lead to confusing notifications and ticket/issue >> comments associated w/ the respective Trac-ticket and/or GitHub >> pull-request. > > that’s a valid point. > > Is there maybe a way to disable all #-number-parsing on GitHub? But I > haven’t seen it... Not that I know of; I'd be a bit suprised though if it was indeed possible, as it's a core feature of GitHub (and after all, you can't disable the PR-submission either) Cheers, hvr

1 0

Re: dropWhileEndLE breakage
by David Feuer 03 Oct '14

03 Oct '14

Simon Peyton Jones asked > What's going on here? No other library module defines this function, except in Cabal! > Simon That was my fault; I'm very sorry. I had added that function (similar to Data.List.dropWhileEnd, but not the same) to compiler/utils/Util.lhs and to another module that used it, and then forgot it was not available in libraries/base/GHC/. Since neither Phab nor I run Windows, there was little hope of catching the mistake before it went out. I believe Joachim Breitner has fixed the problem now by using Data.List.dropWhileEnd to construct that error message—the difference in behavior doesn't matter there. David Feuer

1 0

cabal directory structure under /libraries/ for a lib that uses Rts.h
by Ömer Sinan Ağacan 02 Oct '14

02 Oct '14

Hi all, I'm trying to implement https://ghc.haskell.org/trac/ghc/ticket/5364 , I did the coding part but I'm having trouble compiling it/adding it as a part of GHC libraries. My library is just one hsc file with a line `#include "Rts.h"` in it. Any ideas what should I do to make it compiled with GHC? Thanks.. --- Ömer Sinan Ağacan http://osa1.net

2 3

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