Difference between revisions of "GHC/Type system"
< GHC
Jump to navigation
Jump to search
| (16 intermediate revisions by 6 users not shown) | |||
| Line 1: | Line 1: | ||
| − | + | [[Category:GHC|Type system]] |
|
| + | <span style='font-size: x-large; font-weight: bold'>Type system extensions in GHC</span> |
||
| − | GHC comes with a rather large collection of type-system extensions (beyond Haskell 98). They are all documented in the [http://www.haskell.org/ghc/docs/latest/html/users_guide/ |
+ | GHC comes with a rather large collection of type-system extensions (beyond Haskell 98). They are all documented in the [http://www.haskell.org/ghc/docs/latest/html/users_guide/ghc-language-features.html user manual], but this page is a place to record user-oriented observations, notes, and suggestions on how to use them. |
| + | * '''[[GHC/Indexed_types|Indexed data types]]''' |
||
| − | == Overlapping instances == |
||
| + | * '''[[GHC/TypeHoles|Agda-like "holes" in GHC]]''' |
||
| − | |||
| + | * '''[[GHC/Stand-alone deriving declarations|"Stand-alone deriving" declarations]]''' |
||
| − | Here an [http://www.haskell.org//pipermail/glasgow-haskell-bugs/2006-July/006808.html interesting message] about the interaction of existential types and overlapping instances. |
||
| + | * '''[[GHC/TypeSigsAndAmbiguity|Type signatures and ambiguity]]''' |
||
| − | |||
| + | * '''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/type-class-extensions.html#instance-decls relevant sections of the user manual]. Here is an appliation note about [[GHC/AdvancedOverlap|advanced use of overlapping instances]], combined with functional dependencies. |
||
| − | == Indexed data types and indexed newtypes == |
||
| − | |||
| − | [[GHC/Indexed_types|Indexed 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]. |
||
| − | |||
| − | == Stand-alone deriving clauses == |
||
| − | |||
| − | Bjorn Bringert has recently implemented "stand-alone deriving" declarations, documented briefly here [http://www.haskell.org/ghc/dist/current/docs/users_guide/type-extensions.html#stand-alone-deriving]. There are a few loose ends which I summarise here: |
||
| − | |||
| − | * The current syntax is |
||
| − | <haskell> |
||
| − | deriving Show for T |
||
| − | </haskell> |
||
| − | There seems to be a consensus that this would be better: |
||
| − | <haskell> |
||
| − | derive instance Show T |
||
| − | </haskell> |
||
| − | : so that it looks more like a regular instance declaration. Here <hask>derive</hask> is not a new keyword; it's a "special-id", distinguished by the following <hask>instance</hask> keyword. |
||
| − | |||
| − | * Because it looks like a regular instance declaration, it would arguably be reasonable to require the programmer to supply the context. It seems odd to say: |
||
| − | <haskell> |
||
| − | derive instance Show (T a) |
||
| − | </haskell> |
||
| − | : and perhaps cleaner to say |
||
| − | <haskell> |
||
| − | derive instance Show a => Show (T a) |
||
| − | </haskell> |
||
| − | : (At the moment, the compiler figures out the appropriate context, but at some point that automation may run out of steam.) |
||
| − | |||
| − | * GHC's "newtype deriving mechanism" (see [http://www.haskell.org/ghc/dist/current/docs/users_guide/type-extensions.html#newtype-deriving]) should obviously work in a standalone deriving setting too. But perhaps it can be generalised a little. Currently you can only say |
||
| − | <haskell> |
||
| − | deriving C a for Foo |
||
| − | </haskell> |
||
| − | : (where Foo is the newtype), and get an instance for <hask>(C a Foo)</hask>. But what if you want and instance for <hask>C Foo a</hask>, where the new type is not the last parameter. You can't do that at the moment. However, even with the new instance-like syntax, it's not clear to me how to signal the type to be derived. Consider |
||
| − | <haskell> |
||
| − | newtype Foo = F Int |
||
| − | newtype Bar = B Bool |
||
| − | derive instance C Foo Bar |
||
| − | </haskell> |
||
| − | : Which of these thee instances do we want? |
||
| − | <haskell> |
||
| − | instance C Foo Bool => C Foo Bar |
||
| − | instance C Int Bar => C Foo Bar |
||
| − | instance C Int Bool => C Foo Bar |
||
| − | </haskell> |
||
| − | : The obvious way to signal this is to give the instance context (just as above). This is perhaps another reason for having an explicit instance context in a standalone deriving declaration. |
||
| − | |||
| − | * Incidentally, notice that the third of the alternatives in the previous bullet unwraps two newtypes simultaneously. John Meacham suggested this example: |
||
| − | <haskell> |
||
| − | class SetLike m k where |
||
| − | instance SetLike IntSet Int where |
||
| − | |||
| − | newtype Id = Id Int |
||
| − | newtype IdSet = IdSet IntSet |
||
| − | |||
| − | derive instance SetLike IntSet Int => SetLike IdSet Id |
||
| − | </haskell> |
||
| − | |||
| − | * Suppose two modules, M1 and M2 both contain an identical standalone deriving declaration |
||
| − | <haskell> |
||
| − | derive Show T |
||
| − | </haskell> |
||
| − | : Then, can you import M1 and M2 into another module X and use show on values of type T, or will you get an overlapping instance error? Since both instances are derived in the very same way, their code must be identical, so arguably we can choose either. (There is some duplicated code of course.) |
||
| − | ----------------------- |
||
Revision as of 16:43, 31 October 2012
Type system extensions in GHC
GHC comes with a rather large collection of type-system extensions (beyond Haskell 98). They are all documented in the user manual, but this page is a place to record user-oriented observations, notes, and suggestions on how to use them.
- Indexed data types
- Agda-like "holes" in GHC
- "Stand-alone 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.