On Mon, Sep 17, 2012 at 1:02 PM, Sjoerd Visscher <span dir="ltr"><<a href="mailto:sjoerd@w3future.com" target="_blank">sjoerd@w3future.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word">Hi,<div><br></div><div>Note that nobody was suggesting two pragmas with incompatible behaviors, only to have just one symbol reserved to still be able to have type operator variables.</div>
</div></blockquote><div><br></div><div>An issue with reserving a symbol for type operator variables is it doesn't help you today.</div><div><br></div><div>7.6.1 is already released. </div><div><br></div><div>This means that any change in behavior would have to be in 7.6.2 at the earliest. Assuming the bikeshedding could complete and Simon et al. frantically patched the code tomorrow, rushing to release a 7.6.2 before the platform release.</div>
<div><br></div><div>Failing that, you'd have a whole release cycle to wait through, probably a platform, before you could go back to your old behavior, and then your code would have some strange gap of GHC version numbers over which it didn't work.</div>
<div><br></div><div>Everyone would have to pretend 7.6.1 never happened, or and break anyone's code that was already written for 7.6, so instead of one breaking change, we'd now have two.</div><div><br></div><div>
For instance, I'm already using ~> in '<a href="http://github.com/ekmett/indexed.git" target="_blank">github.com/ekmett/indexed.git</a>' for natural transformations and I am loving it, and would be sad to lose it to the choice of ~ as a herald, similarly it would make the >~c~> trick more verbose, and ~ is particularly terrible for operators like ~+~. </div>
<div><br></div><div>Other herald choices lead to different issues, '.' is slightly better for the other operators, but makes kind of ugly arrows, plus some day i'd _really_ like to be able to use . as a type constructor for functor composition! It is currently reserved at the type level as an almost accidental consequence of the way forall gets parsed today.</div>
<div><br></div><div>I really like Iavor's entirely-in-language way of addressing the issue, due in part to it providing even better associativity than the existing approach, and honestly, even if GHC HQ was somehow convinced to set aside an ad hoc herald for type variables, I'd probably start using it in my code. (probably sandwiching between something like :- and :> for old GHC compatibility). I really like that I can just call the Category c, and just get >~c~> or something similar as its arrows. This feels more notationally accurate to me.</div>
<div><br></div><div>It also has two major benefits compared to any proposal for adding different heralds:</div><div><br></div><div>1.) It is compatible with old code, code written with 7.6.1 and I suppose future code, since (:) is such a remarkably awkward choice of herald for the reasons already documented that it seems an unlikely choice. </div>
<div><br></div><div>2.) I can program with it today.</div><div><br></div><div>I just realized if you don't want to worry about collisions with the type naturals from GHC.TypeLits, and didn't care about pre-7.6 compatibility, you could strip the notation down all the way to </div>
<div><br></div><div><font face="courier new, monospace">cmap :: CFunctor f c d => (x -c> y) -> f x -d> f y</font></div><div><font face="courier new, monospace"><br></font></div><div><div>This is even shorter than the conventional</div>
</div><div><font face="courier new, monospace"><br></font></div><div><font face="courier new, monospace">cmap :: CFunctor f (~>) (~~>) => (x ~> y) -> f x ~~> f y</font></div><div><br></div><div>Which turns the "but it is longer" argument against it on its head. ;)</div>
<div><br></div><div>-Edward</div></div>