exprType and existentials
Calling `exprType` on: case enumFromStepN Int $fNumInt (I# 1) (I# 1) x of wild Stream s1 ostep t ds1 -> Left s1 ((Int, (Int, Int)), s1) t gives: Either s1 ((Int, (Int, Int)), s1) Which is problematic, as the type variable 's1' is unbound outside of the alternative RHS! Unfolding the scrutinee and case-reducing gives: Left (Int, Int) ((Int, (Int, Int)), (Int, Int)) ((,) Int Int (I# 1) (case x of n1 I# ipv ? n1)) Calling `exprType` now gives: Either (Int, Int) ((Int, (Int, Int)), (Int, Int)) That is, `s1` was `(Int, Int)` in this case. Is it expected that `exprType` behaves this way? Or should I file a ticket? I realize the type of the scrutinee (in this case Stream Int) gives no indication as to the existential type... and I'm not sure how you would get it without making exprType do some kind of evaluation, but it would be nice if exprType at least failed if it doesn't have enough information... Andrew ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Linking to changeset on wiki
I was asking about this a while ago,apparently the main blocker to reenabling the auto linking is updating the debian box that hosts trac and thus the version of trac.in the mean time, what i've done in my tickets is include a link to the github mirror of the commits,eg https://github.com/ghc/ghc/commit/1d3fa868d139fb9a8a5e8b0e408c4c70389db8c3with the pattern being https://github.com/ghc/ghc/commit/$CommitHashHere --Carter SchonwaldOn June 11, 2013 at 3:21:26 PM, Geoffrey Mainland (mainl...@apeiron.net) wrote: What is the magical incantation for linking to a changeset in a bug report/on the trac wiki? i can't for the life of me figure it out. Thanks, Geoff ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Proposal: better library management ideas (was: how to checkout proper submodules)
On 06/12/2013 12:37 PM, Ian Lynagh wrote: > On Wed, Jun 12, 2013 at 12:54:38AM +0200, Daniel Trstenjak wrote: >> >>> I guess [the merge commits] may not cause any actual problems, >>> but it's certainly nicer >>> not having them (which is what using submodules gives us). > > Just to clarify, my problem isn't so much that there are merge commits > (although it would still be nicer if there weren't), but that it is hard > to see whether we are in the same state as upstream, or to see what the > differences between us and upstream are. > >> I don't quite understand how you should get rid of these merge commits >> by using submodules, > > With submodules we can do > > cd libraries/Cabal > git reset --hard > cd .. > git commit -a > > and we will jump to that commit, without needing to merge it with the > commit that we were at before. > >> You can get rid of these merge commit by using the '--rebase' option of git-pull. > > We can't rebase, as these patches are in everyone else's GHC tree. Only if you have pushed the "ghc" tree. If it is only local, then rebasing is just fine. And, I would argue, desirable. For the record, I am in favor of moving everything to submodules. Geoff ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Proposal: better library management ideas (was: how to checkout proper submodules)
On Wed, Jun 12, 2013 at 12:54:38AM +0200, Daniel Trstenjak wrote: > > > I guess [the merge commits] may not cause any actual problems, > > but it's certainly nicer > > not having them (which is what using submodules gives us). Just to clarify, my problem isn't so much that there are merge commits (although it would still be nicer if there weren't), but that it is hard to see whether we are in the same state as upstream, or to see what the differences between us and upstream are. > I don't quite understand how you should get rid of these merge commits > by using submodules, With submodules we can do cd libraries/Cabal git reset --hard cd .. git commit -a and we will jump to that commit, without needing to merge it with the commit that we were at before. > You can get rid of these merge commit by using the '--rebase' option of > git-pull. We can't rebase, as these patches are in everyone else's GHC tree. Thanks Ian -- Ian Lynagh, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
