<div dir="ltr">FWIW printf-mauke has a TH quoter: <a href="http://hackage.haskell.org/packages/archive/printf-mauke/0.5.1/doc/html/Text-Printf-Mauke-TH.html">http://hackage.haskell.org/packages/archive/printf-mauke/0.5.1/doc/html/Text-Printf-Mauke-TH.html</a><br>

</div><div class="gmail_extra"><br><br><div class="gmail_quote">On 6 September 2013 20:05, 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">

I&#39;d prefer strongly typed formatting too, although I&#39;m not sure I&#39;m<br>
smart enough to learn the cool-looking package you point to :-).<br>
However, we are unlikely to remove Text.Printf as a formatting option<br>
for those who prefer &quot;stringly typed&quot; (nice pun!). An option I&#39;d<br>
thought about is to actually process the format string using Template<br>
Haskell :-). It would make the calling convention a little<br>
syntactically-different, I guess, but would let me use my comfortable<br>
old printf format strings and still get static typechecking.<br>
<br>
In any case, in my motivating application<br>
(<a href="http://github.com/BartMassey/hseq" target="_blank">http://github.com/BartMassey/hseq</a> -- yes, it&#39;s the Haskell sequence)<br>
I am forced by the existing spec to expose printf format strings to<br>
the user. Bleah, but there I am.<br>
<span class="HOEnZb"><font color="#888888"><br>
--Bart<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
On Fri, Sep 6, 2013 at 4:48 AM, Christopher Done &lt;<a href="mailto:chrisdone@gmail.com">chrisdone@gmail.com</a>&gt; wrote:<br>
&gt; I prefer a well-typed extensible combinator approach like:<br>
&gt;<br>
&gt; <a href="http://chrisdone.com/holey-format/Text-Format.html" target="_blank">http://chrisdone.com/holey-format/Text-Format.html</a><br>
&gt;<br>
&gt; than the stringly typed approach of printf.<br>
&gt;<br>
&gt;<br>
&gt; On 6 September 2013 04:16, Bart Massey &lt;<a href="mailto:bart@cs.pdx.edu">bart@cs.pdx.edu</a>&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt; Greetings all! It&#39;s been many years since I have been subscribed to<br>
&gt;&gt; this list, and now I come back with a big ask. :-) Here goes...<br>
&gt;&gt;<br>
&gt;&gt; (tl;dr: I&#39;d like to replace Text.Printf with a &quot;better&quot; version I&#39;ve<br>
&gt;&gt; written. I could use some help to get this to happen.)<br>
&gt;&gt;<br>
&gt;&gt; If you go to <a href="http://github.com/BartMassey/extensible-printf" target="_blank">http://github.com/BartMassey/extensible-printf</a> you will<br>
&gt;&gt; find Text.Printf.Extensible, my substantially-rewritten version of<br>
&gt;&gt; Text.Printf.<br>
&gt;&gt;<br>
&gt;&gt; * The primary goal, as the name suggests, was to allow the extension<br>
&gt;&gt; of Haskell printf to user datatypes, a goal I achieved by modifying<br>
&gt;&gt; the Text.Printf source using roughly the approach suggested by Meacham<br>
&gt;&gt; and Marlow in an old email thread here. By the time I was done with<br>
&gt;&gt; everything, I&#39;d made changes to much of the source, but the structure<br>
&gt;&gt; and a lot of the code is still recognizably there. I documented<br>
&gt;&gt; everything a bit more in the process of figuring out how it all<br>
&gt;&gt; worked.<br>
&gt;&gt;<br>
&gt;&gt; * A second goal was to extend printf to support as much of the C<br>
&gt;&gt; printf(3) format string syntax as seemed practicable: I did that, too.<br>
&gt;&gt; See the documentation for details.<br>
&gt;&gt;<br>
&gt;&gt; * A third goal was to produce something that was somewhat tested. See<br>
&gt;&gt; <a href="http://github.com/BartMassey/printf-tests" target="_blank">http://github.com/BartMassey/printf-tests</a> for a test suite of 300+<br>
&gt;&gt; tests, gathered from printf test suites found on the Internet, that<br>
&gt;&gt; Text.Printf.Extensible passes. (Text.Printf fails about half of them.)<br>
&gt;&gt;<br>
&gt;&gt; * A fourth goal was to be 100% backward-compatible with the existing<br>
&gt;&gt; Text.Printf. I haven&#39;t done sufficient testing to be sure, but on the<br>
&gt;&gt; face of it existing programs should just work.<br>
&gt;&gt;<br>
&gt;&gt; So here&#39;s the deal: I could just push this onto Hackage as<br>
&gt;&gt; extensible-printf and call it a day. However, then we&#39;d still have a<br>
&gt;&gt; known-broken and not-extensible standard Text.Printf, and<br>
&gt;&gt; extensible-printf would have to be maintained forever. Better, IMHO,<br>
&gt;&gt; is to just replace the existing Text.Printf code with my rework.<br>
&gt;&gt;<br>
&gt;&gt; One issue is that I would love to have someone who is not me shepherd<br>
&gt;&gt; this work through the Library Submission process. I don&#39;t read this<br>
&gt;&gt; email list so regularly, and so I&#39;d be bad at facilitating an active<br>
&gt;&gt; discussion.<br>
&gt;&gt;<br>
&gt;&gt; Another issue is that a patch should be done to merge the tiny changes<br>
&gt;&gt; in Text.Printf.Extensible.AltFloat back into Numeric. I&#39;m happy to<br>
&gt;&gt; prepare such a patch, but someone will have to show me how to build<br>
&gt;&gt; base so that I can test my work. Is there any way to do it without<br>
&gt;&gt; also building GHC? I tried, and became very confused.<br>
&gt;&gt;<br>
&gt;&gt; A final issue has to do with the return type of Text.Printf.printf,<br>
&gt;&gt; which is polymorphic between String and IO a. I&#39;m sure this seemed<br>
&gt;&gt; like a good idea at the time, but it&#39;s not so ideal today: GHC gives a<br>
&gt;&gt; warning when printf is used at IO a unless you explicitly ignore the<br>
&gt;&gt; result. (Worse still, if you mistakenly try to *use* the result,<br>
&gt;&gt; you&#39;ll likely end up with a run-time error.) The obvious choices are<br>
&gt;&gt; to somehow get printf to return String / IO () instead, something I<br>
&gt;&gt; could not figure out the type magic to accomplish, or to provide some<br>
&gt;&gt; alternate names for non-return-polymorphic functions. I&#39;m leaning<br>
&gt;&gt; toward putFmt, hPutFmt (synonymous with hprintf) and sFmt, but I&#39;m<br>
&gt;&gt; totally open to alternate suggestions. If we go forward, though, it<br>
&gt;&gt; seems like this is something we should fix one way or the other. If<br>
&gt;&gt; someone can figure out the type magic, we could fix it regardless.<br>
&gt;&gt;<br>
&gt;&gt; Thanks much for reading! Regardless, the code was fun to write, and I<br>
&gt;&gt; hope it will be useful to someone other than me.<br>
&gt;&gt;<br>
&gt;&gt; Bart Massey<br>
&gt;&gt; <a href="mailto:bart@cs.pdx.edu">bart@cs.pdx.edu</a><br>
&gt;&gt;<br>
&gt;&gt; _______________________________________________<br>
&gt;&gt; Libraries mailing list<br>
&gt;&gt; <a href="mailto:Libraries@haskell.org">Libraries@haskell.org</a><br>
&gt;&gt; <a href="http://www.haskell.org/mailman/listinfo/libraries" target="_blank">http://www.haskell.org/mailman/listinfo/libraries</a><br>
&gt;<br>
&gt;<br>
</div></div></blockquote></div><br></div>