#2855: Surprising type (family) type derived
---------------------------------+------------------------------------------
Reporter: guest | Owner:
Type: feature request | Status: new
Priority: normal | Milestone:
Component: Compiler | Version: 6.10.1
Severity: normal | Resolution:
Keywords: | Difficulty: Unknown
Testcase: | Os: Unknown/Multiple
Architecture: Unknown/Multiple |
---------------------------------+------------------------------------------
Comment (by simonpj):
Several things going on here. Concerning type signatures, it's indeed
annoying that a program can have an inferred type that can't be used as a
type signature. I plan to fix that by rejecting both programs. You won't
like that, but it's silly to accept one but not the other. I think
there's a ticket open for this, but I'm not sure which one...
Concering "I want it to be the x from the dictionary (C a) that I'm
passing". Yes, I know. That's why I said it's vexing; indeed, the solution
you suggest is the ''only'' solution that will work. All I'm saying is
that this is a new form of reasoning, which GHC does not in any way
implement at the moment. It'd take a bit of study to figure out how to do
it, or indeed if there is any well-behaved, principal solution. If you can
work one out, do tell us!
Can you not design your functions so that they take at least one parameter
that does not live inside a type-function application? Or, would you be
willing for your type functions to be injective, or would that be too
restrictive for your application?
Simon
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2855#comment:4>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
_______________________________________________
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
