Proposal: Replace Text.Printf with extensible, complete version

Bart Massey bart at
Tue Sep 17 10:38:24 CEST 2013

Thanks much for the fast response!

My printf tests are at
They're kind of cross-implementation, so I'm not sure of the best way
to fold them into GHC: if I capture them now, GHC won't automatically
track future improvements. Give me another month to work on one more
batch of tests with my students, and I'll end up with something

I should warn you that the unit tests are most of the testing I've
done. I would be happy if someone not me compiled a few packages
against the new code and verified that there isn't some horrible
obvious thing that should be fixed before the 7.8 release. I'll try to
be especially available over the next few days for any bug reports.

If the patch is OK, I think I'll leave things that way for now. In the
future, I'll try to send a pull request instead.

Release Note: Rewrote portions of Text.Printf, and made changes to
Numeric (added Numeric.showFFloatAlt and Numeric.showGFloatAlt) and
GHC.Float (added formatRealFloatAlt) to support it. Rewritten version
is extensible to user types, adds a "generic" format specifier "%v",
extends the printf spec to support much of C printf(3) functionality,
and fixes the spurious GHC warnings about using Text.Printf.printf at
(IO a) and ignoring the return value.


On Tue, Sep 17, 2013 at 12:30 AM, Joachim Breitner
<mail at> wrote:
> Hi Bart,
> Am Montag, den 16.09.2013, 18:28 -0700 schrieb Bart Massey:
>> Greetings. This proposal is an extension of previous discussion on the
>> libraries list about replacing Text.Printf with my updated version
>> that provides extensibility of printf to user datatypes and implements
>> much more of the C printf spec, while maintaining
>> backward-compatibility with existing users of printf.
> thanks for bringing this officially to the committee’s attention.
> Given the backwards-compatible form of the patch, and the broad support,
> I believe we can go on and include this in base now. Unless someone
> complains today, I’ll look into pushing this tomorrow.
>> There is a separable proposal to move Text.Printf from base into its
>> own package. I support that proposal, but believe that we can take
>> them in either order, and this is the part I know how to do :-).
> I don’t think we should remove it from base for this release. Hopefully
> we’ll tackle the larger base-splitting-and-shimming for the next
> release, and it would be nicer to our users to have only one round of
> “if you use feature x, which was removed from base, use package y”.
> Too bad that we don’t have module re-exports on the package level,
> otherwise I had suggested that you
>  * create a package printf that re-exports Text.Printf and
>  * base:Text.Printf gives a deprecation warning, telling people to use
>    Text.Printf (note the same name) from the printf package.
> But that is a side-note and not related to the proposal at hand.
>> Attached please find a patch that implements the proposal. Note that
>> it also makes slight, backward-compatible modification to Numeric and
>> GHC.Float to avoid a whole bunch of pointless code duplication. The
>> printf patch is kind of ugly because so much of Text/Printf.hs has
>> been replaced. Let me know if it would be better to just provide the
>> whole source. The patch applies and builds against my current
>> top-of-tree GHC.
> I find links to github branches (e.g. something like
> <>) nice,
> but of course the patch is fine.
> In your original mail you said that you created a testsuite. Is there a
> way to include them in base’s testsuite? Note that there are already
> Text.Printf-tests in there.
> But be careful about the copyright of the files you copy there; if
> required add their status to LICENSE.
> OTOH, if we expect to to separate the code again in the next release and
> you don’t find base’s testrunner pleasant to work with, you can skip
> this.
> Would you mind writing a sentence or short paragraph for the release
> notes, describing your changes?
>> While I would welcome shortening the discussion given how much has
>> already been discussed, Monday 30 September is two weeks from today,
>> so I will treat that as the discussion deadline unless I hear
>> otherwise.
> As I said, I don’t think we need the full discussion time frame, and
> rather try to squeeze this into base for 7.8. (My opinion, if someone
> disagrees please shout.)
> Greetings,
> Joachim
> --
> Joachim Breitner
>   e-Mail: mail at
>   Homepage:
>   ICQ#: 74513189
>   Jabber-ID: nomeata at
> _______________________________________________
> Libraries mailing list
> Libraries at

More information about the Libraries mailing list