<div dir="ltr"><div>I prefer a well-typed extensible combinator approach like:<br><br><a href="http://chrisdone.com/holey-format/Text-Format.html">http://chrisdone.com/holey-format/Text-Format.html</a><br><br></div>than the stringly typed approach of printf.<br>

</div><div class="gmail_extra"><br><br><div class="gmail_quote">On 6 September 2013 04:16, Bart Massey <span dir="ltr">&lt;<a href="mailto:bart@cs.pdx.edu" target="_blank">bart@cs.pdx.edu</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

Greetings all! It&#39;s been many years since I have been subscribed to<br>
this list, and now I come back with a big ask. :-) Here goes...<br>
<br>
(tl;dr: I&#39;d like to replace Text.Printf with a &quot;better&quot; version I&#39;ve<br>
written. I could use some help to get this to happen.)<br>
<br>
If you go to <a href="http://github.com/BartMassey/extensible-printf" target="_blank">http://github.com/BartMassey/extensible-printf</a> you will<br>
find Text.Printf.Extensible, my substantially-rewritten version of<br>
Text.Printf.<br>
<br>
* The primary goal, as the name suggests, was to allow the extension<br>
of Haskell printf to user datatypes, a goal I achieved by modifying<br>
the Text.Printf source using roughly the approach suggested by Meacham<br>
and Marlow in an old email thread here. By the time I was done with<br>
everything, I&#39;d made changes to much of the source, but the structure<br>
and a lot of the code is still recognizably there. I documented<br>
everything a bit more in the process of figuring out how it all<br>
worked.<br>
<br>
* A second goal was to extend printf to support as much of the C<br>
printf(3) format string syntax as seemed practicable: I did that, too.<br>
See the documentation for details.<br>
<br>
* A third goal was to produce something that was somewhat tested. See<br>
<a href="http://github.com/BartMassey/printf-tests" target="_blank">http://github.com/BartMassey/printf-tests</a> for a test suite of 300+<br>
tests, gathered from printf test suites found on the Internet, that<br>
Text.Printf.Extensible passes. (Text.Printf fails about half of them.)<br>
<br>
* A fourth goal was to be 100% backward-compatible with the existing<br>
Text.Printf. I haven&#39;t done sufficient testing to be sure, but on the<br>
face of it existing programs should just work.<br>
<br>
So here&#39;s the deal: I could just push this onto Hackage as<br>
extensible-printf and call it a day. However, then we&#39;d still have a<br>
known-broken and not-extensible standard Text.Printf, and<br>
extensible-printf would have to be maintained forever. Better, IMHO,<br>
is to just replace the existing Text.Printf code with my rework.<br>
<br>
One issue is that I would love to have someone who is not me shepherd<br>
this work through the Library Submission process. I don&#39;t read this<br>
email list so regularly, and so I&#39;d be bad at facilitating an active<br>
discussion.<br>
<br>
Another issue is that a patch should be done to merge the tiny changes<br>
in Text.Printf.Extensible.AltFloat back into Numeric. I&#39;m happy to<br>
prepare such a patch, but someone will have to show me how to build<br>
base so that I can test my work. Is there any way to do it without<br>
also building GHC? I tried, and became very confused.<br>
<br>
A final issue has to do with the return type of Text.Printf.printf,<br>
which is polymorphic between String and IO a. I&#39;m sure this seemed<br>
like a good idea at the time, but it&#39;s not so ideal today: GHC gives a<br>
warning when printf is used at IO a unless you explicitly ignore the<br>
result. (Worse still, if you mistakenly try to *use* the result,<br>
you&#39;ll likely end up with a run-time error.) The obvious choices are<br>
to somehow get printf to return String / IO () instead, something I<br>
could not figure out the type magic to accomplish, or to provide some<br>
alternate names for non-return-polymorphic functions. I&#39;m leaning<br>
toward putFmt, hPutFmt (synonymous with hprintf) and sFmt, but I&#39;m<br>
totally open to alternate suggestions. If we go forward, though, it<br>
seems like this is something we should fix one way or the other. If<br>
someone can figure out the type magic, we could fix it regardless.<br>
<br>
Thanks much for reading! Regardless, the code was fun to write, and I<br>
hope it will be useful to someone other than me.<br>
<br>
Bart Massey<br>
<a href="mailto:bart@cs.pdx.edu">bart@cs.pdx.edu</a><br>
<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>
</blockquote></div><br></div>