<div dir="ltr"><br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="Ih2E3d">> That's an interesting idea. It appears to use the same idea as ShowS, but<br>
> more generally with lists and not just strings.<br>
<br>
</div>The difference-list approach to solving the appending problem is classic.<br>
There's a variant for unification-based logic languages as well. Both are<br>
functional takes on the imperative approach of keeping a tail pointer.<br>
Dons just took the time to package it up for us all :)<br>
<div class="Ih2E3d"></div></blockquote><div><br>Yes, I've seen it before in UU.DData.Seq. Though, where it was that I originally found it, I don't remember, but it wasn't the uulib. I didn't know what a "difference list" was, so I didn't pay much attention when Don released it.<br>
<br><a href="http://hackage.haskell.org/packages/archive/uulib/0.9.5/doc/html/UU-DData-Seq.html">http://hackage.haskell.org/packages/archive/uulib/0.9.5/doc/html/UU-DData-Seq.html</a><br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
If you're planning on releasing the code, I'd suggest a different spelling<br>
of (.+.) though. The (.X.) pattern for a family of operators is pretty<br>
common, so it's good to avoid it for modules that want to be used in<br>
combination with many others. YMMV and all that.<br>
<div><div></div><div class="Wj3C7c"></div></div></blockquote><div><br>That sounds reasonable. My only motivations were to keep the operators short, sweet, and somewhat representative. Any suggestions are welcome.<br><br>
Sean<br></div></div></div>