#10875: Unexpected defaulting of partial type signatures and inconsistent behaviour when -fdefer-typed-holes is set. -------------------------------------+------------------------------------- Reporter: holzensp | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: | PartialTypeSignatures TypedHoles Operating System: MacOS X | Architecture: x86_64 Type of failure: Incorrect | (amd64) warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by holzensp): If you're done with the refactoring and want someone to help test, by all means let me know. I see your point with regards to the defaulting rule from the language definition. In light of the typing rules, I'm unsure whether I would consider a typed hole to be like any other term. With a variable-typed term, like `undefined`, I agree that the typing rules should find ''whatever'' type satisfies. My interpretation of a typed hole, however, is that I'm asking GHC: "Please tell me what you expect me to put in here." After typing up my comment, though, I understand that `RealFrac b => a_bound_by_the_type_of_foo -> b` actually is not the correct type, because `round` actually binds `b`. In other words, it's not just that `round` imposes a `RealFrac` constraint on `b`, but the `b` of the hole should be precisely the same `b` as that of `round`. Somehow it should be something like `RealFrac b_bound_by_the_type_of_round => a_bound_by_the_type_of_foo -> b_bound_by_the_type_of_round`. I admit it's complicated, but purely from a TypedHoles user perspective, I think defaulting is... less then intuitive (fully aware of the subjectivity of that term). -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10875#comment:4 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler