Re: Equality check for types that respects type families? (#9582)
Thanks, Simon, for the quick answer (see ticket #9582). --Andreas
On 17.09.2014 23:58, Andreas Abel wrote:
Looking at bug #9582
Associated Type Synonyms do not unfold in InstanceSigs
https://ghc.haskell.org/trac/ghc/ticket/9582
I found that the given type in an instance signature is compared to the
expected type using Type.eqType, which does not seem to know about type
families.
https://github.com/ghc/ghc/blob/master/compiler/typecheck/TcInstDcls.lhs
-- Check that any type signatures have exactly the right type
check_inst_sig hs_ty@(L loc _)
= setSrcSpan loc $
do { sig_ty - tcHsSigType (FunSigCtxt sel_name) hs_ty
; inst_sigs - xoptM Opt_InstanceSigs
; if inst_sigs then
unless (sig_ty `eqType` local_meth_ty)
(badInstSigErr sel_name local_meth_ty)
...
https://github.com/ghc/ghc/blob/master/compiler/types/Type.lhs
eqType :: Type - Type - Bool
-- ^ Type equality on source types. Does not look through @newtypes@ or
-- 'PredType's, but it does look through type synonyms.
-- Watch out for horrible hack: See Note [Comparison with OpenTypeKind]
Question: Is there a (monadic) function for checking type equality
which knows about the current type family rules in scope and honors them?
Maybe the better question is where to find it, since there should be
such a beast (used in the type checker somewhere to compare expected
with inferred types).
Cheers,
Andreas (new to the GHC source code)
--
Andreas AbelDu bist der geliebte Mensch.
Department of Computer Science and Engineering
Chalmers and Gothenburg University, Sweden
andreas.a...@gu.se
http://www2.tcs.ifi.lmu.de/~abel/
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
RE: D202: Injective type families
Dear GHC devs I'm sure I should know this, but if I want to build a Phab patch, to reproduce some issue (example below). How would I do that? If Phabs were branches in the GHC repo I could say Git checkout phab/D202 That would be cool. I know how to do that. But I don't think they are. So what do I do? Simon | -Original Message- | From: nore...@phabricator.haskell.org | [mailto:nore...@phabricator.haskell.org] | Sent: 18 September 2014 09:35 | To: Simon Peyton Jones | Subject: [Differential] [Commented On] D202: Injective type families | | jstolarek added a comment. | | I made two important adjustments: | | - first of all I removed the `result` from the parser and lexer. | Instead of `result` I'm planning to use type variable introduced by | the user for the result (as described in [[ | https://ghc.haskell.org/trac/ghc/wiki/InjectiveTypeFamilies#Proposal7 | | Proposal 7 ]] on the wiki. | | - following Richard's suggestion I changed `InjectivityInfo` to | contain `[Located name]` instead of `[LHsType name]`. But I keep | getting Not in scope errors. When I try to compile: | ``` | type family F a :: r | r - a where | F a = a | ``` | I get errors that `r` and `a` are not in scope. According to my | tracing line 1149 of RnSource.lhs is responsible for this. I looked at | other code in this module and it seems to me that `bindHsTyVars` | should bring these variables into scope when renaming `r - a`. I have | no idea why this does not happen. Simon, help? | | Also, build error reported by Harbormaster is nonsense. | | REPOSITORY |rGHC Glasgow Haskell Compiler | | REVISION DETAIL |https://phabricator.haskell.org/D202 | | REPLY HANDLER ACTIONS |Reply to comment, or !reject, !abandon, !reclaim, !resign, !rethink, | !unsubscribe. | | To: jstolarek, simonpj, austin | Cc: goldfire, simonmar, ezyang, carter ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: D202: Injective type families
I believe you do this with: arc patch D123456 The arcanist docs are handy: https://secure.phabricator.com/book/phabricator/article/arcanist/ On Thu, Sep 18, 2014 at 9:38 AM, Simon Peyton Jones simo...@microsoft.com wrote: Dear GHC devs I'm sure I should know this, but if I want to build a Phab patch, to reproduce some issue (example below). How would I do that? If Phabs were branches in the GHC repo I could say Git checkout phab/D202 That would be cool. I know how to do that. But I don't think they are. So what do I do? Simon | -Original Message- | From: nore...@phabricator.haskell.org | [mailto:nore...@phabricator.haskell.org] | Sent: 18 September 2014 09:35 | To: Simon Peyton Jones | Subject: [Differential] [Commented On] D202: Injective type families | | jstolarek added a comment. | | I made two important adjustments: | | - first of all I removed the `result` from the parser and lexer. | Instead of `result` I'm planning to use type variable introduced by | the user for the result (as described in [[ | https://ghc.haskell.org/trac/ghc/wiki/InjectiveTypeFamilies#Proposal7 | | Proposal 7 ]] on the wiki. | | - following Richard's suggestion I changed `InjectivityInfo` to | contain `[Located name]` instead of `[LHsType name]`. But I keep | getting Not in scope errors. When I try to compile: | ``` | type family F a :: r | r - a where | F a = a | ``` | I get errors that `r` and `a` are not in scope. According to my | tracing line 1149 of RnSource.lhs is responsible for this. I looked at | other code in this module and it seems to me that `bindHsTyVars` | should bring these variables into scope when renaming `r - a`. I have | no idea why this does not happen. Simon, help? | | Also, build error reported by Harbormaster is nonsense. | | REPOSITORY |rGHC Glasgow Haskell Compiler | | REVISION DETAIL |https://phabricator.haskell.org/D202 | | REPLY HANDLER ACTIONS |Reply to comment, or !reject, !abandon, !reclaim, !resign, !rethink, | !unsubscribe. | | To: jstolarek, simonpj, austin | Cc: goldfire, simonmar, ezyang, carter ___ 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: Should we occasionally merge haddock master into ghc-head?
On 09/18/2014 10:30 PM, Edward Z. Yang wrote: Hello Mateusz and all, With ghc-head and master being developed concurrently, I am wondering if GHC developers should be allowed to occasionally merge in changes from master. Seems like a good service which would help Mateusz out a bit when it comes time to update master for the next version GHC. Or is there some reason we shouldn't do this? Cheers, Edward Hi, tl;dr: Far too much effort on the GHC side for very little gain on Haddock side makes the master/ghc-head split lose part of its function. Longer version: As I mentioned on IRC, my plan at GHC release time is not to just merge from ghc-head. Changes by GHC team tend to be small, fixes due to API changes. Ideally what would happen is that I sit down near release date and cherry-pick it all out, maybe even squashing it first into a ‘update for next GHC’ commit as that makes looking at the actual diff between branches much easier – we do not care what changed between day 1 of 7.9 until last day of 7.9, we only care about what changed between 7.8.3 and 7.10.x-justbeforerc1. One of the large reasons why I wanted to move out Haddock from GHC tree is that we (Haddock) do not have to go through these API changes at all, we're only there for the final release. I think this makes cherry-picking more suited to merging ghc-head → master. But your question is master → ghc-head. I think it is not necessary for you to do so. We have already taken steps for compatibility with 7.8.2 and even split Haddock up further into more packages. This means that not only would this merge be very unpleasant to do, it'd also be unpleasant to maintain thereafter. As I don't plan merging ghc-head back in, it does not greatly reduce labour for me when it comes to it but it makes it painful for GHC folk. The only reason you might have to merge master → ghc-head would therefore be if GHC needed features from master at which point cherry-picking those features is easier than merging the whole thing. I think it makes sense to think of it as Haddock now being disjoint software that GHC happens to use, needs to patch sometimes, and simply contributes those (finalised) patches to Haddock at GHC release time. Once these merges are done, you can restart ghc-head for 7.11 from master at that point, rather than trying to go through merges and try to keep in sync throughout the process. Basically ‘master’ is the upstream and ‘ghc-head’ is your private fork that you maintain and contribute back when the time comes. I can develop quickly and test against 7.8.3 because I don't have to worry about impacting HEAD and you can develop and test against HEAD because you don't have to worry about impacting the versions in the wild. -- Mateusz K. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: [commit: ghc] master's head updated: Add default case (fixes -Werror) (4d90e44)
Dear devs, I must admit I screwed this up again, I wanted to push on my branch git push darcs 4d90e44101559800947ce3cd7fd8704dc520b332:wip/generics-propeq-conservative but muscle memory betrayed me and I pushed like this: git push darcs 4d90e44101559800947ce3cd7fd8704dc520b332:master Sorry for the messup. How can I repair this? I did not intend to merge my work yet. It is not totally wrong though. It has three failures, but they are okay. I have a commit in my tree for that, but my firewall won't let them out (they are more than a kilobyte :-( The changes should be reviewed on the branch, and some changes are still expected. Second thought, how could this happen? Was this just a fast-forward of master ? Git seems to be a dangerous tool. Cheers and all help welcome, (also review comments regarding this WIP), remorsefully, Gabor On 9/19/14, g...@git.haskell.org g...@git.haskell.org wrote: Repository : ssh://g...@git.haskell.org/ghc Branch 'master' now includes: e12a6a8 Propositional equality for Datatype meta-information 0a8e6fc Make constructor metadata parametrized (with intended parameter - datatype) f097b77 Implement sameConstructor cc618e6 get roles right and fix a FIXME 79c7125 Actually parametrize the Constructor with the Datatype 7bd4bab Supply a reasonable name (should be derived from d_name tho) 09fcd70 Use 'd_name' as the name (should be derived from d_name tho) 4d90e44 Add default case (fixes -Werror) ___ ghc-commits mailing list ghc-comm...@haskell.org http://www.haskell.org/mailman/listinfo/ghc-commits ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
