Coercible class (Was: newtype wrappers)
simonpj at microsoft.com
Mon Sep 16 05:53:21 UTC 2013
The Coercible class really is a language feature, as much as (say) implicit parameters. There is no new *syntax*, but a (Coercible a b) constraint behaves differently to other normal class constraints. It has no instances; rather it has some specific rules about how Coercible constraints are solved. Or, if you like, it changes the type system of the language.
(It's an unusual language feature because it is "emabled" simply by importing the right library, rather than by a flag. Though I suppose you could argue for -XNewtypeCoercions in order to force a module to document that it uses the feature. I'm happy as-is.)
Internally, both Coercible constraints and implicit parameters are represented as class constraints. The difference is that implicit parameters have special syntax -- and we *could* have special syntax for Coercible constraints (though I'm not seriously suggesting that).
So I suggest that the Coercible class has a user-guide section as a peer to implicit parameters, that explains the feature and the solving rules. Maybe the stuff on generalised newtype deriving should move there, under a heading of "Extended support for newtype" or something?
I'm guessing that all this material is already drafted in the Haddock comments. (In a taxi so can't check.) Maybe it belongs in the user manual with a link to it? The library documentation can more or less say (a) Coercible is not an ordinary type class (b) you can't declare instances of it (c) look in the user manual.
| -----Original Message-----
| From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Joachim
| Sent: 15 September 2013 22:57
| To: ghc-devs at haskell.org
| Subject: Re: Coercible class (Was: newtype wrappers)
| Am Sonntag, den 15.09.2013, 17:49 -0400 schrieb Richard Eisenberg:
| > To be clear, I'm not asking for an explanation for me -- I think I
| > know what's going on here.
| Sorry if you got that impression; I have no doubt that you understand the feature
| (possibly better than me!)
| > I just think that this behavior requires a small section in the user
| > manual, because it's a user-visible change to the language that GHC
| > compiles. I would say the haddock docs could point to the user manual,
| > to avoid the duplication (which I similarly dislike, for sure!)
| Well, the question of which location points to which one is close to bikeshedding,
| so I’ll just pull the “I did it” card here (until shouted down by a larger crowd). But
| a mention in the user manual will not hurt:
| Can you suggest a section? Then I’ll put in a small paragraph with an reference to
| the haddocks.
| Joachim Breitner
| e-Mail: mail at joachim-breitner.de
| Homepage: http://www.joachim-breitner.de
| ICQ#: 74513189
| Jabber-ID: nomeata at joachim-breitner.de
More information about the ghc-devs