<div><div>I'ved chewed on the associativity and precedence issue for <> a little bit. Here are my thoughts.</div><div><br></div><div>infixl 6 <> would match the precedence of +, which is nice on paper, and how I happen to implement (+) in Data.Monoid.Sugar in the monoids library. I now believe that it is not quite right.</div>
</div><div><br></div><div><div>On paper infixr vs. infixl is basically irrelevant because the result is monoidal, but in practice infixr tends to work better for a lot of real world monoids we care about like list appending. Take a look at the behavior of ((... ++ b) ++ c) vs (a ++ (b ++ ...) for a compelling justification for why infixr is probably better in practice for the poster child of the monoid lineup.</div>
<div><br></div></div><div>Ross's infixr 5 >< in Data.Sequence is the same precedence and fixity as ++, which also seems like a good answer at first, but infixr 5 <> would change the behavior of programs that use Text.PrettyPrint.HughesPJ, which relies on the fixity of <> and <+> being higher than $$ and $+$ which are infixl 5.</div>
<div><br></div><div><div>The original proposed infixr/l 4 is low enough that you couldn't even mix the use of <> with the various comparators from Eq and Ord, and it exacerbates all of the above issues -- by inverting the precedence of $$ and <> -- so I think it should be off the table. For similar reasons I don't like lowering the fixity off $$ and $+$ in HughesPJ to 4 to permit infixr 5 <>.</div>
</div><div><br></div><div>So, in light of all of that, it would seem that the most compatible general change would be to set:</div><div><br></div><div>infixr 6 <></div><div><br></div><div>and to change the associativity of <+> in Text.PrettyPrint.HughesPJ to match, so that they can be intermixed. Version 3.0 of the HughesPJ combinators, released back in 1997 has fixed any performance regression that would be caused by changing the associativity. I hope everyone will have upgraded by now. ;)</div>
<div><br></div><div>This binds slightly tighter than ++, but retains the same asymptotic performance, works with == <=, etc. and only requires the minor associativity tweak to HughesPJ, which should be allowed just fine under the pretty printer combinator laws, so exxisting HughesPJ code should continue to run just fine, and other existing code wouldn't be using the new operator, so shouldn't require any tweaks.</div>
<div><br></div><div>-Edward Kmett</div><div><br></div><div><div class="gmail_quote">On Fri, Sep 18, 2009 at 7:18 AM, 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 Thu, 2009-09-17 at 14:37 +0100, Ross Paterson wrote:<br>
<br>
> This proposal seems to have got stuck. Everyone wants an infix operator,<br>
> but we can't agree what it should be.<br>
><br>
> I prefer using a new operator instead of generalizing ++ (or +, *, &&<br>
> or ||), because I think that a monoid operation is so abstract that it<br>
> needs a name that doesn't suggest one of the special cases. (I like <>)<br>
<br>
</div>Nice. For some reason I much prefer a symbol like <> to one like +>.<br>
<br>
I want to say that it's because it looks symmetric, though of course<br>
mappend, ++ are associative not symmetric, so it's not a very good<br>
argument. But I still like it! :-)<br>
<br>
So I guess we should adjust the proposal, or make a new one.<br>
* Suggest the name <> (which so far seems to have popular support)<br>
* Get rid of the suggestion for a reverse mappend operator<br>
* As Krasimir says, include in the proposal that we would deal<br>
with the existing libraries that use a local <> for their<br>
mappend operator (at least Text.PrettyPrint).<br>
<br>
One thing we've not mentioned much is operator precedence. Existing<br>
uses:<br>
infixr 5 Data.Sequence.><<br>
infixl 6 Text.PrettyPrint.<><br>
Existing proposal about (+>)<br>
infixl 4 +><br>
<font color="#888888"><br>
Duncan<br>
</font><div><div></div><div class="h5"><br>
_______________________________________________<br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org">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>
</div></div></blockquote></div><br></div>