<div dir="ltr">This puts the constraint on the wrong thing.<div><br></div><div><div>I did argue for a pragma-like syntax for the annotations when they were first proposed, as the need for library authors to hide these behind CPP pragmas bothers me a great deal, but I think for better or worse that syntax decision is largely behind us.</div>
</div><div><br></div><div><br></div><div><br></div><div>A type-class driven approach does have some promise, but that said, it can't look like what you've written.</div><div><br></div><div>What you've written:</div>
<div><br></div><div><font face="courier new, monospace">data Nominal k => Map k a</font></div><div><br></div><div>is saying something about the argument k, not about if you can turn <font face="courier new, monospace">Map k</font> into <font face="courier new, monospace">Map k'</font><font face="arial, helvetica, sans-serif">, which is actually about Map, k is just along for the ride.</font></div>
<div><br></div><div>Really what we're talking about is that the next argument is representational as applied. Also, the right 'open world' version would be to talk about it as classes would be:</div><div><br></div>
<div><font face="courier new, monospace">class Representational t where</font></div><div><font face="courier new, monospace">  rep :: Coercion a b -> Coercion (t a) (t b)</font></div><div><font face="courier new, monospace"><br>
</font></div><div><font face="courier new, monospace">class Representational t => Phantom t where</font></div><div><font face="courier new, monospace">  phantom :: Coercion (t a) (t b)</font></div><div><br></div><div>With "Nominal" simply being the absence of either of those instances.</div>
<div><br></div><div><font face="courier new, monospace">data Map k a</font></div><div><br></div><div>would need</div><div><br></div><div><font face="courier new, monospace">instance Representational (Map k) </font></div><div>
<br></div><div>since the 'a' can be coerced as it has a representational role.</div><div><br></div><div><font face="courier new, monospace">instance Representational (->)</font></div><div><font face="courier new, monospace">instance Representational ((->) a)</font></div>
<div><br></div><div>But there are actually still open issues I don't know how to solve, even with this approach.</div><div><br></div><div>-Edward</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Mar 24, 2014 at 11:36 AM, Mark Lentczner <span dir="ltr"><<a href="mailto:mark.lentczner@gmail.com" target="_blank">mark.lentczner@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Again, sorry for the 11:59 meddling....<div><br></div><div>The syntax of role annotations is very heavy weight, and requires lots of CPP where there wasn't need before.  Two thoughts:</div>
<div><br></div>

<div>1) Couldn't we do something like use "cue" type constraints? For example, assuming the default is representational, and that phantom can just be inferred, all we need is a way to indicate nominal:</div>


<div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div><font face="courier new, monospace">data (Nominal k) => Map k v = ...</font></div></blockquote></div><div><br></div><div>This could then probably be easily made to compile in other compilers with some null library implementation of Nominal</div>


<div><br></div><div>2) An alternative to the above. We generally frown on constraints in a data / newtype declaration, but perhaps this is exactly the case for them, whereby we can now do away with the type role syntax: We can infer nominal if there are <i>any</i> constraints on a type parameter, <i>representational</i> if there are none, and <i>phantom </i>if there are no mentions in the right hand side:</div>


<div><div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><font face="courier new, monospace">data (Eq k) => Map k v = ...</font></blockquote></div></div><div><br></div><div>This seems even nicer and just works with all compilers... but perhaps I'm missing something. (Yes, I imagine there are type constraints that shouldn't force nominal, but perhaps not worth worrying about?)</div>


<div><br></div><div><br></div><div>Mind you, this all just about syntax... the issue of what is the implication for libraries of the default being representational is still at hand.</div>​</div>
<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><br>
<br></blockquote></div><br></div>