<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Verdana;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-reply;
font-family:"Verdana","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri","sans-serif";
mso-fareast-language:EN-US;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-GB" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Verdana","sans-serif";color:#1F497D;mso-fareast-language:EN-US">It’s in the nature of type systems that as well as excluding bad programs they also exclude some good programs. So if we tighten
up the type system (and GND allows seg-faults at the moment) that is certain to exclude some good programs.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Verdana","sans-serif";color:#1F497D;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Verdana","sans-serif";color:#1F497D;mso-fareast-language:EN-US">Would you like a flag to say “allow me to use GeneralisedNewtypeDeriving even if it is dangerous to do so”?<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Verdana","sans-serif";color:#1F497D;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Verdana","sans-serif";color:#1F497D;mso-fareast-language:EN-US">Simon<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Verdana","sans-serif";color:#1F497D;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt">
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif"">From:</span></b><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri","sans-serif""> ghc-devs [mailto:ghc-devs-bounces@haskell.org]
<b>On Behalf Of </b>Johan Tibell<br>
<b>Sent:</b> 12 October 2013 00:15<br>
<b>To:</b> Richard Eisenberg<br>
<b>Cc:</b> Stephanie Weirich; ghc-devs@haskell.org Devs<br>
<b>Subject:</b> Re: small improvement to roles mechanism<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">Let me start by saying that I'm happy we're trying to fix the GND problem. Thanks for working on that.<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">That being said: is this ready for mainstream consumption? We're forcing this on everyone without any language pragma or flags to opt-in/out. That is bad if we're not sure we're doing the right thing in some cases or if we're causing spurious
failures. At ICFP I got the impression that very few people will be affected, but Bryan's result suggests there are more people than I thought.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><o:p> </o:p></p>
<div>
<p class="MsoNormal">On Thu, Oct 10, 2013 at 8:26 PM, Richard Eisenberg <<a href="mailto:eir@cis.upenn.edu" target="_blank">eir@cis.upenn.edu</a>> wrote:<o:p></o:p></p>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm">
<p class="MsoNormal">In Bryan's recent test of GHC 7.8 against all of Hackage, there were three spurious errors caused by lack of role abstraction. Here are the class definitions where a nominal parameter is inferred, probably against the wishes of the author:<br>
<br>
from logict-0.2.3/Control.Monad.Logic.Class:<br>
> class (MonadPlus m) => MonadLogic m where<br>
> msplit :: m a -> m (Maybe (a, m a))<br>
<br>
from monadLib-3.5.2/MonadLib:<br>
> class (Monad m) => ReaderM m i | m -> i where<br>
> ask :: m i<br>
<br>
from base/Control.Arrow:<br>
> class Arrow a => ArrowApply a where<br>
> app :: a (a b c, b) c<br>
<br>
In each of these, the last parameter of the class is given a nominal role because it appears as the parameter of a type variable. However, in each case, it appears as the parameter of a *class* type variable. This means that, if we somehow knew that the class
author wanted the class to be usable with GND, we could simply check every instance declaration for that class to make sure that the relevant concrete instantiation has the right role. For example, when the user writes, for example<br>
<br>
> instance ArrowApply Foo where …<br>
<br>
we check that Foo's first parameter has a representational role. If it doesn't, then the instance is rejected.<br>
<br>
An alternative, somewhat heavier idea would be to represent roles as class constraints. We could have<br>
<br>
> class NextParamNominal (c :: k)<br>
> class NextParamRepresentational (c :: k)<br>
<br>
GHC could "generate" instances for every datatype definition. For example:<br>
<br>
> type role Map nominal representational<br>
> data Map k v = …<br>
<br>
would induce<br>
<br>
> instance NextParamNominal Map<br>
> instance NextParamRepresentational (Map k)<br>
<br>
Users would not be able to write these instances -- they would have to be generated by GHC. (Alternatively, there could be no instances, just a little magic in the constraint solver. Somewhat like Coercible.)<br>
<br>
Then, the classes above would just have to add a superclass, like this:<br>
<br>
> class (Arrow a, NextParamRepresentational a) => ArrowApply a where<br>
> app :: a (a b c, b) c<br>
<br>
The role inference mechanism would be made aware of role constraints and use this one to derive that ArrowApply is OK for GND.<br>
<br>
This "heavier" approach has a similar upshot to the first idea of just checking at instance declarations, but it is more customizable and transparent to users (I think).<br>
<br>
<br>
I'm not sure I'm advocating for this change (or volunteering to implement before the release candidate), but I wanted to document the idea and get any feedback that is out there. This would fix the breakage we've seen without totally changing the kind system.<br>
<br>
Thanks,<br>
Richard<br>
<br>
PS: Due credit is to migmit for suggesting the type-class idea on glasgow-haskell-users.<br>
_______________________________________________<br>
ghc-devs mailing list<br>
<a href="mailto:ghc-devs@haskell.org">ghc-devs@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/ghc-devs" target="_blank">http://www.haskell.org/mailman/listinfo/ghc-devs</a><o:p></o:p></p>
</blockquote>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</div>
</body>
</html>