GHC TypeFamilies extension

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

GHC TypeFamilies extension

Simon Peyton Jones
We could do that, but personally I don't think it's worth it.  I'm ccing ghc-devs in case anyone has a strong opinion.

Simon

| -----Original Message-----
| From: Richard Eisenberg [mailto:eir at cis.upenn.edu]
| Sent: 27 August 2013 21:45
| To: Simon Peyton-Jones; Dimitrios Vytiniotis
| Cc: Stephanie Weirich
| Subject: GHC TypeFamilies extension
|
| Hi Simon, Dimitrios,
|
| Among the various responses I've gotten to closed type families was a
| complaint (made by a fellow Penn student, Daniel Wagner) about
| extensions that change their meaning over time. Here is why: If a
| package requires the use of a certain extension, it can declare the
| extension in the cabal file, so that end users get a nice error message
| if their GHC is out of date. However, if a package uses closed type
| families, no such declaration is possible; an old GHC will just die with
| a parse error. There are ways to insist on a certain version of GHC or a
| version of the base library, but that doesn't seem great, either.
|
| On the other hand, I'm loathe to add yet another extension
| ClosedTypeFamilies, forcing yet another pragma at the top of
| programmers' files.
|
| Instead, we came up with this intermediate solution:
| - Introduce two new extensions, OpenTypeFamilies and ClosedTypeFamilies
| - TypeFamilies would imply both of these
| - Appropriate checks would be made and error messages improved
|
| Now, users can still use TypeFamilies to get both flavors of type
| families, but a package maintainer can specify ClosedTypeFamilies in a
| cabal file to control which versions of GHC are usable.
|
| I'm still not 100% convinced this is the right idea, but there is enough
| sense in it to ask.
|
| What do you think? If you all think this is a good enough idea, I'll
| forward to glasgow-haskell-users for a wider discussion.
|
| Thanks,
| Richard