Agreed. <span></span><br><br>On Monday, September 30, 2013, Edward A Kmett  wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div>I think if someone went through the effort of writing a patch so you could at least introduce local operator names with an explicit forall, like with ScopedTypeVariables and the proposed explicit type applications then it'd probably be accepted.<br>
<br>Sent from my iPhone</div><div><br>On Sep 30, 2013, at 2:25 PM, Conal Elliott <<a href="javascript:_e({}, 'cvml', 'conal@conal.net');" target="_blank">conal@conal.net</a>> wrote:<br><br></div><blockquote type="cite">
<div><div dir="ltr"><div><div>-1.<br><br></div>I'm hoping we don't get more deeply invested in the syntactic change in GHC 7.6 that removed the possibility of symbolic type variables ("~>", "*", "+", etc). I had a new job and wasn't paying attention when SPJ polled the community. From my perspective, the loss has much greater scope than the gain for type level naturals. I'd like to keep the door open to the possibility of bringing back the old notation with the help of a language pragma. It would take a few of us to draft a proposal addressing details.<br>


<br></div><div>Not at all meaning to start a syntax debate on this thread. Just an explanation of my -1 for the topic at hand.<br><br></div><div>- Conal<br></div><div><br></div>-- Conal<br></div><div class="gmail_extra">

<br>
<br><div class="gmail_quote">On Sat, Sep 28, 2013 at 9:57 PM, Edward Kmett <span dir="ltr"><<a href="javascript:_e({}, 'cvml', 'ekmett@gmail.com');" target="_blank">ekmett@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">As part of the discussion about Typeable, GHC 7.8 is going to include a Data.Type.Equality module that provides a polykinded type equality data type.<div><br></div><div>I'd like to propose that we rename this type to (==) rather than the (:=:) it was developed under. </div>



<div><br></div><div>We are already using (+), (-), (*), etc. at the type level in type-nats, so it would seem to fit the surrounding convention.</div><div> </div><div>I've done the work of preparing a patch, visible here:<br>



</div><div><br></div><div><a href="https://github.com/ekmett/packages-base/commit/fb47f8368ad3d40fdd79bdeec334c0554fb17110" target="_blank">https://github.com/ekmett/packages-base/commit/fb47f8368ad3d40fdd79bdeec334c0554fb17110</a><br>


</div>
<div><br></div><div><div>Thoughts?</div><div><br></div></div><div><div>Normally, I'd let this run the usual 2 week course, but we're getting down to the wire for 7.8's release. Once 7.8 ships, we'd basically be stuck with the current name forever.</div>



<div><br></div></div><div>Discussion Period: 1 week<span><font color="#888888"><br></font></span></div><span><font color="#888888"><div><br></div><div>-Edward Kmett</div></font></span></div>


<br>_______________________________________________<br>
Libraries mailing list<br>
<a href="javascript:_e({}, 'cvml', 'Libraries@haskell.org');" target="_blank">Libraries@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/libraries" target="_blank">http://www.haskell.org/mailman/listinfo/libraries</a><br>
<br></blockquote></div><br></div>
</div></blockquote></div></blockquote>