RE: Question about Haskell AST
desugarModule returns a GHC.DesugaredModule Inside a DesugaredModule is a field dm_core_module :: HscTypes.ModGuts Inside a ModGuts is a field mg_binds :: [CoreSyn.CoreBind] And there are your bindings! Does that tell you what you wanted to know? Simon PS: When you have it clear, would you like to augment the Wiki http://haskell.org/haskellwiki/GHC/As_a_library to describe what you learned? That way others can benefit. | -Original Message- | From: glasgow-haskell-users-boun...@haskell.org [mailto:glasgow-haskell- | users-boun...@haskell.org] On Behalf Of Jane Ren | Sent: 10 January 2011 17:21 | To: glasgow-haskell-users@haskell.org | Subject: Question about Haskell AST | | Hi, | | I need to be able to take a piece of Haskell source code and get an | simplified, typed, intermediate representation of the AST, which means I need | to use compiler/coreSyn/CoreSyn.lhs | | So I'm first trying to get the desguaredModule of the source code with | ... | modSum - getModSummary $ mkModuleName ... | p - parseModule modSum | t - typecheckModule p | d - desugarModule t | | Now I'm really stuck on figuring out how to connect the variable d of type | desugaredModule to compiler/coreSyn/CoreSyn.lhs to get Expr patterns like | App, Let, Case, etc. | | Also, is it correct to get the deguaredModule first? At least CoreSyn.lhs | seems to suggest this. | | Any suggestions would be greatly apprecia | ___ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: RFC: migrating to git
On 10 Jan 2011, at 22:37, Daniel Peebles wrote: So the basic point seems to be: if you know how to use a tool, you don't usually curse and swear when you use it. If you don't, you tend to swear a lot! There is a meta-point though - how easy is it to learn the tool? Regards, Malcolm ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: RFC: migrating to git
On 11/01/2011 00:36, rocon...@theorem.ca wrote: On Mon, 10 Jan 2011, Simon Marlow wrote: It's time to consider again whether we should migrate GHC development from darcs to (probably) git. From our perspective at GHC HQ, the biggest problem that we would hope to solve by switching is that darcs makes branching and merging very difficult for us. I don't develop GHC so you shouldn't really listen to me, but if you think Darcs makes branching and merging very diffcult then you won't like Git et al. which make braching and merging impossible since their semantic model is broken. Thanks for this. I distilled your example into a shell script that uses git, and demonstrates that git gets the merge wrong: http://hpaste.org/42953/git_mismerge Still, git could get this merge right, it just doesn't (I know there are more complex cases that would be very hard for git to get right). I suspect that in practice this rarely matters, because context-based merging usually does the right thing. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: RFC: migrating to git
On Mon, Jan 10, 2011 at 12:19 PM, Simon Marlow marlo...@gmail.com wrote: It's time to consider again whether we should migrate GHC development from darcs to (probably) git. From our perspective at GHC HQ, the biggest problem that we would hope to solve by switching is that darcs makes branching and merging very difficult for us. We have a few branches of HEAD that are very painful to keep merged with HEAD, and we would almost certainly have more branches if the overhead were lower. In some sense the overhead is self-inflicted because we have the no-conflict policy in the mainline repository, but that is to avoid problems with darcs' merging algorithms (both performance and correctness). We are still using darcs v1 patches rather than v2, but there are known problems with v2 which are preventing us from upgrading. The darcs team have been making great strides with performance, but conflict handling remains a serious problem. The darcs roadmap doesn't show this being fixed in the near future http://wiki.darcs.net/Roadmap Rebase support is coming, and it does work, though the workflow is a bit laborious. Besides the branching/merging/conflict issue, switching to git would give us plenty of side benefits, notably via access to a wealth of tool support. Making contribution easy is important to us too, and there are a lot of people using git. The cost of switching is quite high, which is one reason we decided to stay with darcs last time. We have multiple repos that need to be converted, and for some of them, where the repo is being shared with other projects, we may have to mirror rather than convert in place. We're prepared to put in the effort if the gains would be worthwhile though (offers of help are more than welcome!). We're intrested in opinions from both active and potential GHC developers/contributors. Let us know what you think - would this make life harder or easier for you? Would it make you less likely or more likely to contribute? Cheers, Simon I've contributed a small patch or two to GHC before, but nothing major. I expect the future to be similar: I don't anticipate doing any major work on GHC, but if I come across an itch which I see as within my capabilities and worthwhile to scratch, I might scratch it. I didn't have any problem with darcs after getting over the (not so steep) learning curve, and if GHC were to switch to git, I don't think I would have any problem with that either. So I guess I'll just be fine either way. ___ Cvs-ghc mailing list cvs-...@haskell.org http://www.haskell.org/mailman/listinfo/cvs-ghc -- Work is punishment for failing to procrastinate effectively. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: RFC: migrating to git
On Mon, 10 Jan 2011, Roman Leshchinskiy wrote: It also seems to make finding buggy patches rather hard. Have a look at `git bisect`. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ HUMBER THAMES DOVER WIGHT PORTLAND: NORTH BACKING WEST OR NORTHWEST, 5 TO 7, DECREASING 4 OR 5, OCCASIONALLY 6 LATER IN HUMBER AND THAMES. MODERATE OR ROUGH. RAIN THEN FAIR. GOOD. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: RFC: migrating to git
On 11/01/2011, at 16:14, Tony Finch wrote: On Mon, 10 Jan 2011, Roman Leshchinskiy wrote: It also seems to make finding buggy patches rather hard. Have a look at `git bisect`. I'm aware of git bisect. It doesn't do what I want. I usually have a pretty good idea of which patch(es) might have caused a problem and I want to unpull it and its dependencies. This is easy in darcs; I have no idea how to do that in git. Roman ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: RFC: migrating to git
On 11 January 2011 19:07, Roman Leshchinskiy r...@cse.unsw.edu.au wrote: On 11/01/2011, at 16:14, Tony Finch wrote: On Mon, 10 Jan 2011, Roman Leshchinskiy wrote: It also seems to make finding buggy patches rather hard. Have a look at `git bisect`. I'm aware of git bisect. It doesn't do what I want. I usually have a pretty good idea of which patch(es) might have caused a problem and I want to unpull it and its dependencies. This is easy in darcs; I have no idea how to do that in git. This form of dependency tracking is done manually in Git via topic/feature branches. Undoing the patch would the mean undoing the merge, which can be done via git rebase -i. (The -i part is just for a nicer user interface). Now whether manual dependency tracking is better than darcs' automatic tracking is another question. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: RFC: migrating to git
Hello, On Mon, Jan 10, 2011 at 12:49 PM, Roman Leshchinskiy r...@cse.unsw.edu.auwrote: On 10/01/2011, at 13:27, Simon Marlow wrote: It would be a prerequisite to switching that a GHC developer only has to use one VCS. So we either migrate dependencies to git, or mirror them in GHC-specific git branches. I'm not sure how that is going to work. It might well be possible to build GHC using only git. But most GHC developers also contribute to various libraries which are often quite intimately linked to GHC. In particular, GHC patches are often accompanied by library patches. Unless all those libraries switch to git, too, we'll have to use both git and darcs which would be *really* annoying. If GHC and the libraries on which it depends were in git (migrated, or mirrored), then we could use git sub-modules to track the dependencies between changes to GHC and changes to the libraries. Roughly, the workflow would be like this: 1. Make a change to the library and commit it. 2. Make a change to GHC. 3. Make a GHC commit which records the change and the dependency on the commit in the library repository. This is useful because when someone gets the changes to GHC, they would know that they need to update their library as well (and there is tool support to make all updates automatically). This kind of dependency is not at all obvious with our current workflow. The same method works for going back to a previous state of the project, where one can rewind the libraries to their old versions too. -Iavor ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: RFC: migrating to git
On 11/01/2011, at 21:41, Iavor Diatchki wrote: If GHC and the libraries on which it depends were in git (migrated, or mirrored), then we could use git sub-modules to track the dependencies between changes to GHC and changes to the libraries. Roughly, the workflow would be like this: 1. Make a change to the library and commit it. 2. Make a change to GHC. 3. Make a GHC commit which records the change and the dependency on the commit in the library repository. What about dependencies which go the other way? Actually, the dependency is often mutual: the GHC change won't work without the library change and the library change won't work without the GHC change. Does git support this? This is useful because when someone gets the changes to GHC, they would know that they need to update their library as well (and there is tool support to make all updates automatically). This kind of dependency is not at all obvious with our current workflow. IMO, darcs-all works pretty well. I don't think I ever really had problems with missing library patches. The same method works for going back to a previous state of the project, where one can rewind the libraries to their old versions too. This would be useful. Unfortunately, git's rewinding seems rather crippled compared to darcs. Roman ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: RFC: migrating to git
On 11/01/11 21:57, Roman Leshchinskiy wrote: On 11/01/2011, at 21:41, Iavor Diatchki wrote: If GHC and the libraries on which it depends were in git (migrated, or mirrored), then we could use git sub-modules to track the dependencies between changes to GHC and changes to the libraries. Roughly, the workflow would be like this: 1. Make a change to the library and commit it. 2. Make a change to GHC. 3. Make a GHC commit which records the change and the dependency on the commit in the library repository. What about dependencies which go the other way? Actually, the dependency is often mutual: the GHC change won't work without the library change and the library change won't work without the GHC change. Does git support this? As I understand it, the GHC repo would specify the required version of the library repo. Right now with darcs we don't get to do this, so if you want to back out the GHC tree to a previous state, it's impossible to back the libraries up to the right point too (I've found this quite annoying when tracking down regressions in the past). With submodules, when you make a combined GHC/library change, the relationship between the two changes would be recorded in the GHC repo, which is exactly what you want. This is useful because when someone gets the changes to GHC, they would know that they need to update their library as well (and there is tool support to make all updates automatically). This kind of dependency is not at all obvious with our current workflow. IMO, darcs-all works pretty well. I don't think I ever really had problems with missing library patches. I often see problems where someone has done 'darcs pull' rather than './darcs-all pull' and ended up with a weird compilation error as a result. If we could eliminate this source of errors, it would be a major win. If submodules actually work for what we want to do, this would be a good reason to move to git, I think. The same method works for going back to a previous state of the project, where one can rewind the libraries to their old versions too. This would be useful. Unfortunately, git's rewinding seems rather crippled compared to darcs. In what way? Cheers, Simon BTW, I just translated the GHC darcs repo into git using darcs-fastconvert (cabal install darcs-fastconvert). It took less than 10 minutes and seems to have done the right thing. I'll try to put this up tomorrow for people to play with. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: RFC: migrating to git
On 11/01/2011, at 22:20, Simon Marlow wrote: On 11/01/11 21:57, Roman Leshchinskiy wrote: IMO, darcs-all works pretty well. I don't think I ever really had problems with missing library patches. I often see problems where someone has done 'darcs pull' rather than './darcs-all pull' and ended up with a weird compilation error as a result. If we could eliminate this source of errors, it would be a major win. A quick look at the docs seems to indicate that we'd need to do git pull git submodule update which doesn't look like a win over darcs-all. Also, I completely fail to understand what git submodule update does. It doesn't seem to pull all patches from the master repo. The git submodule docs are even worse than the rest of the git docs which is rather discouraging. This would be useful. Unfortunately, git's rewinding seems rather crippled compared to darcs. In what way? Thomas says that it doesn't do automatic dependency tracking which looks like a huge weakness to me. Personally, I haven't been able to successfully unpull non-consecutive chunks of patches with git so far but I only tried 2 or 3 times before giving up. Roman ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: New codegen failing test-cases
Hello Simon, Have you gotten a chance to look at these two hunks? (see below) Thanks, Edward Excerpts from Edward Z. Yang's message of Fri Dec 10 10:59:26 -0500 2010: Ok, I've got a patch that fixes this segfault. In the process I looked at all patches to Cg* modules after Nov 2009 and looked for changes that weren't applied to the new codegen. I skipped the LLVM patch, but picked up the rest of the blackhole changes. There are, however, two hunks that I am not 100% sure how to translate. hunk ./compiler/codeGen/CgClosure.lhs 477 - stmtC (CmmStore (CmmReg nodeReg) bh_info) + stmtsC [ + CmmStore (cmmOffsetW (CmmReg nodeReg) fixedHdrSize) + (CmmReg (CmmGlobal CurrentTSO)), + CmmCall (CmmPrim MO_WriteBarrier) [] [] CmmUnsafe CmmMayReturn, + CmmStore (CmmReg nodeReg) bh_info +] (the new code uses emits and a different format) hunk ./compiler/codeGen/CgStackery.lhs 20 - pushUpdateFrame, emitPushUpdateFrame, + pushUpdateFrame, pushBHUpdateFrame, emitPushUpdateFrame, A new pushBHUpdateFrame function was added, but I'm not sure how to translate this because the new codegenerator only reads out the offset from the FCode monad and there's no label to speak of. Edward ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: RFC: migrating to git
On Tue, Jan 11 2011, Roman Leshchinskiy wrote: On 11/01/2011, at 22:20, Simon Marlow wrote: On 11/01/11 21:57, Roman Leshchinskiy wrote: This would be useful. Unfortunately, git's rewinding seems rather crippled compared to darcs. In what way? Thomas says that it doesn't do automatic dependency tracking which looks like a huge weakness to me. Personally, I haven't been able to successfully unpull non-consecutive chunks of patches with git so far but I only tried 2 or 3 times before giving up. I think the confusion might just be in terminology and model. Going back to earlier versions in git is trivial, much easier than darcs. Remember, git doesn't store patches. Git stores full snapshots of the tree, with a digraph of dependencies. The trees and history are immutable. The main advantages to darcs are that it can manipulate the sequence of patches better than git. The main advantage of git is that every version is accurately named. If two people have a commit with a given hash, they will have exactly the same files and history. Most projects seem to want most of the history to be immutable, and only do manipulation on recent stuff. Removal of earlier patches is an additional patch that removes it rather than removing it from the history. David ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: RFC: migrating to git
On Tue, 11 Jan 2011, Simon Marlow wrote: Thanks for this. I distilled your example into a shell script that uses git, and demonstrates that git gets the merge wrong: http://hpaste.org/42953/git_mismerge I've posted an annotation at http://hpaste.org/paste/42953/git_mismerge_annotation#p42966 which shows the difference between pulling patches one at a time, and pulling both patches together. Still, git could get this merge right, it just doesn't (I know there are more complex cases that would be very hard for git to get right). I suspect that in practice this rarely matters, because context-based merging usually does the right thing. The operative word being *usually*. Remember what Dijkstra said. :) -- Russell O'Connor http://r6.ca/ ``All talk about `theft,''' the general counsel of the American Graphophone Company wrote, ``is the merest claptrap, for there exists no property in ideas musical, literary or artistic, except as defined by statute.'' ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
