<div class="gmail_quote">On Fri, Sep 18, 2009 at 5:28 PM, Duncan Coutts <span dir="ltr"><<a href="mailto:duncan.coutts@worc.ox.ac.uk">duncan.coutts@worc.ox.ac.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On Fri, 2009-09-18 at 10:04 -0400, Edward Kmett wrote:<br>
> I'ved chewed on the associativity and precedence issue for <> a little<br>
> bit. Here are my thoughts.<br>
<br>
</div>Thanks for the analysis. There's just one bit I don't quite follow.<br>
<div class="im"><br>
> Ross's infixr 5 >< in Data.Sequence is the same precedence and fixity<br>
> as ++, which also seems like a good answer at first, but infixr 5 <><br>
> would change the behavior of programs that use<br>
> Text.PrettyPrint.HughesPJ, which relies on the fixity of <> and <+><br>
> being higher than $$ and $+$ which are infixl 5.<br>
<br>
> The original proposed infixr/l 4 is low enough that you couldn't even<br>
> mix the use of <> with the various comparators from Eq and Ord, and it<br>
> exacerbates all of the above issues -- by inverting the precedence of<br>
> $$ and <> -- so I think it should be off the table. For similar<br>
> reasons I don't like lowering the fixity off $$ and $+$ in HughesPJ to<br>
> 4 to permit infixr 5 <>.<br>
<br>
</div>It's not clear to me why changing the fixity of $$ and $+$ would be bad.<br>
I see that using infixl/r for <> would be bad because we cannot mix >=<br>
etc with <> and there are obviously many types that can be in Monoid and<br>
Ord. On the other hand Doc is not in any type classes except Show. So I<br>
don't see that the point applies to the HughesPJ lib.<br>
<div class="im"><br>
> So, in light of all of that, it would seem that the most compatible<br>
> general change would be to set:<br>
><br>
> infixr 6 <><br>
<br>
</div>Of course one could argue that you might want a type in Monoid and Ord<br>
and have a spare precedence level between <> and >=. But I don't see how </blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">we can claim it's necessary for compatibility reasons.</blockquote>
<div> </div><div>Sorry, I didn't mean to imply that the extra level between <> and == was purely for compatibility with Eq and Ord. Perhaps those were the wrong example, but there is a case to be made for wanting to keep the number of hard-to-predict consequences of precedence changes to a minimum. </div>
<div><div><br></div></div><div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; ">
If we do need a spare precedence level between <> and >= then fine, but<br>all things being equal it seems preferable to go with the same<br>precedence as ++.<br></blockquote><div><br></div></div></div><div><br></div>
<div>I don't know, and I don't know that anyone can know what other operators people have used in code that uses HughesPJ or any of the other pretty printer combinator libraries. Most compelling, is that there is an implicit 'infixr 5 :' in the Prelude and the pretty printer combinator libraries use [Doc] all over the place. So moving one level down would break a lot of pretty printer client code.</div>
<div><br></div><div>As a happy side note Text.PrettyPrint.Leijen already contains infixr 6 <> and requires no changes other than the optional cleanup of using the new operator. ;)</div><div> </div><div>-Edward Kmett</div>
<div><font class="Apple-style-span" color="#888888"><font class="Apple-style-span" color="#000000"><br></font></font></div></div>