GHC/Type system
From HaskellWiki
< GHC(Difference between revisions)
(→Type signatures and ambiguity) 

(9 intermediate revisions by 4 users not shown)  
Line 2:  Line 2:  
<span style='fontsize: xlarge; fontweight: bold'>Type system extensions in GHC</span> 
<span style='fontsize: xlarge; fontweight: bold'>Type system extensions in GHC</span> 

−  GHC comes with a rather large collection of typesystem extensions (beyond Haskell 98). They are all documented in the [http://www.haskell.org/ghc/docs/latest/html/users_guide/typeextensions.html user manual], but this page is a place to record observations, notes, and suggestions on them. 
+  GHC comes with a rather large collection of typesystem extensions (beyond Haskell 98). They are all documented in the [http://www.haskell.org/ghc/docs/latest/html/users_guide/ghclanguagefeatures.html user manual], but this page is a place to record useroriented observations, notes, and suggestions on how to use them. 
−  == Type signatures and ambiguity == 
+  * '''[[GHC/Indexed_typesIndexed data types]]''' 
−  +  * '''[[GHC/TypeHolesAgdalike "holes" in GHC]]''' 

−  It's quite common for people to write a function definition without a type signature, load it into GHCi, use <tt>:t</tt> to see what type it has, and then cutandpaste that type into the source code as a type signature. Usually this works fine, but alas not always. Perhaps this is a deficiency in GHC, but here's one way it can happen: 
+  * '''[[GHC/Standalone deriving declarations"Standalone deriving" declarations]]''' 
−  <haskell> 
+  * '''[[GHC/TypeSigsAndAmbiguityType signatures and ambiguity]]''' 
−  class C a b where 
+  * '''Overlapping instances'''. GHC supports overlapping instances, with carefully specified rules. Make sure you read the [http://www.haskell.org/ghc/docs/latest/html/users_guide/typeclassextensions.html#instancedecls relevant sections of the user manual]. Here is an appliation note about [[GHC/AdvancedOverlapadvanced use of overlapping instances]], combined with functional dependencies. 
−  foo :: a > b 

−  
−  konst :: a > Bool 

−  konst x = True 

−  
−  f :: (C a b) => a > Bool 

−  f x = konst (foo x) 

−  </haskell> 

−  If you compile this code, you'll get this error: 

−  <pre> 

−  Foo1.hs:12:13: 

−  Could not deduce (C a b1) from the context (C a b) 

−  arising from use of `foo' at Foo1.hs:12:1317 

−  Possible fix: add (C a b1) to the type signature(s) for `f' 

−  In the first argument of `konst', namely `(foo x)' 

−  In the expression: konst (foo x) 

−  In the definition of `f': f x = konst (foo x) 

−  </pre> 

−  What's going on? GHC knows, from the type signature that <tt>x::a</tt>. Then applying <tt>foo</tt> means GHC must pick a return type for <tt>foo</tt>, say <tt>b1</tt>, and generates the type constraint <tt>(C a b1)</tt>. The function <tt>konst</tt> just discards its argument, ''so nothing further is known abouut <tt>b1</tt>''. 

−  
−  Now GHC finished typechecking the right hand side of <tt>f</tt>, so next it checks that the constraints ''needed'' in the RHS, namely <tt>(C a b1)</tt>, can be satisfied from the constraints ''provided'' by the type signature, namely <tt>(C a b)</tt>. Alas there is nothing to tell GHC that <tt>b</tt> and <tt>b1</tt> should be identified together; hence the complaint. (Probably you meant to put a functional dependency in the class declaration, thus 

−  <haskell> 

−  class C a b  a>b where ... 

−  </haskell> 

−  but you didn't.) 

−  
−  The surprise is that if you comment out the type signature for <tt>f</tt>, the module will load fine into GHCi! Furthermore <tt>:t</tt> will report a type for <tt>f</tt> that is exactly the same as the type signature that was rejected! 

−  
−  Here's what's happening. Without the type signature, GHC picks an arbitrary type for <tt>x</tt>, say <tt>x::a</tt>. Then applying <tt>foo</tt> means GHC must pick a return type for <tt>foo</tt>, say <tt>b</tt>, and generates the type constraint <tt>(C a b)</tt>. The function <tt>konst</tt> just discards its argument, so nothing further is known abouut <tt>b</tt>. Finally, GHC gathers up all the constraints arising from the right hand side, namely <tt>(C a b)</tt>, and puts them into the inferred type of <tt>f</tt>. So GHC ends up saying that <hask>f :: (C a b) => a > Bool</hask>. 

−  
−  This is probably a very stupid type. Suppose you called <tt>f</tt> thus: <tt>(f 'a')</tt>. Then you'd get a constraint <tt>(C Char b)</tt> where nothing is known about <tt>b</tt>. That would be OK if there was an instance like: 

−  <haskell> 

−  instance C Char b where ... 

−  </haskell> 

−  But in the more likely situation where you had instances that constrain both type parameters, you'd be in trouble: 

−  <haskell> 

−  instance C Char Bool where ... 

−  </haskell> 

−  Now the call gives a <tt>(C Char b)</tt> constraint, with absolutely no way to fix <tt>b</tt> to be <tt>Bool</tt>, or indeed anything else. We're back to very much the same situation as before; it's just that the error is deferred until we call <tt>f</tt>, rather than when we define it. 

−  
−  This behaviour isn't ideal. It really only arises in programs that are ambiguous anyway (that is, they could never really work), but it is undoubtedly confusing. But I don't know how to improve it. Yet, anyway. 

−  
−  == Overlapping instances == 

−  
−  Here an [http://www.haskell.org//pipermail/glasgowhaskellbugs/2006July/006808.html interesting message] about the interaction of existential types and overlapping instances. 

−  
−  == Indexed data types and indexed newtypes == 

−  
−  [[GHC/Indexed_typesIndexed data types]] (including associated data types) are a very recent addition to GHC's type system extensions that is not yet included in the user manual. To use the extension, you need to obtain a version of GHC from [http://hackage.haskell.org/trac/ghc/wiki/Building/GettingTheSources its source repository]. 

−  
−  == Standalone deriving clauses == 

−  
−  Bjorn Bringert has recently implemented [[GHC/Standalone deriving declarations"standalone deriving" declarations]]. 

−   
Revision as of 16:43, 31 October 2012
Type system extensions in GHC
GHC comes with a rather large collection of typesystem extensions (beyond Haskell 98). They are all documented in the user manual, but this page is a place to record useroriented observations, notes, and suggestions on how to use them.
 Indexed data types
 Agdalike "holes" in GHC
 "Standalone deriving" declarations
 Type signatures and ambiguity
 Overlapping instances. GHC supports overlapping instances, with carefully specified rules. Make sure you read the relevant sections of the user manual. Here is an appliation note about advanced use of overlapping instances, combined with functional dependencies.