Text.Printf replacement?

Bart Massey bart at cs.pdx.edu
Fri Sep 6 04:16:59 CEST 2013


Greetings all! It's been many years since I have been subscribed to
this list, and now I come back with a big ask. :-) Here goes...

(tl;dr: I'd like to replace Text.Printf with a "better" version I've
written. I could use some help to get this to happen.)

If you go to http://github.com/BartMassey/extensible-printf you will
find Text.Printf.Extensible, my substantially-rewritten version of
Text.Printf.

* The primary goal, as the name suggests, was to allow the extension
of Haskell printf to user datatypes, a goal I achieved by modifying
the Text.Printf source using roughly the approach suggested by Meacham
and Marlow in an old email thread here. By the time I was done with
everything, I'd made changes to much of the source, but the structure
and a lot of the code is still recognizably there. I documented
everything a bit more in the process of figuring out how it all
worked.

* A second goal was to extend printf to support as much of the C
printf(3) format string syntax as seemed practicable: I did that, too.
See the documentation for details.

* A third goal was to produce something that was somewhat tested. See
http://github.com/BartMassey/printf-tests for a test suite of 300+
tests, gathered from printf test suites found on the Internet, that
Text.Printf.Extensible passes. (Text.Printf fails about half of them.)

* A fourth goal was to be 100% backward-compatible with the existing
Text.Printf. I haven't done sufficient testing to be sure, but on the
face of it existing programs should just work.

So here's the deal: I could just push this onto Hackage as
extensible-printf and call it a day. However, then we'd still have a
known-broken and not-extensible standard Text.Printf, and
extensible-printf would have to be maintained forever. Better, IMHO,
is to just replace the existing Text.Printf code with my rework.

One issue is that I would love to have someone who is not me shepherd
this work through the Library Submission process. I don't read this
email list so regularly, and so I'd be bad at facilitating an active
discussion.

Another issue is that a patch should be done to merge the tiny changes
in Text.Printf.Extensible.AltFloat back into Numeric. I'm happy to
prepare such a patch, but someone will have to show me how to build
base so that I can test my work. Is there any way to do it without
also building GHC? I tried, and became very confused.

A final issue has to do with the return type of Text.Printf.printf,
which is polymorphic between String and IO a. I'm sure this seemed
like a good idea at the time, but it's not so ideal today: GHC gives a
warning when printf is used at IO a unless you explicitly ignore the
result. (Worse still, if you mistakenly try to *use* the result,
you'll likely end up with a run-time error.) The obvious choices are
to somehow get printf to return String / IO () instead, something I
could not figure out the type magic to accomplish, or to provide some
alternate names for non-return-polymorphic functions. I'm leaning
toward putFmt, hPutFmt (synonymous with hprintf) and sFmt, but I'm
totally open to alternate suggestions. If we go forward, though, it
seems like this is something we should fix one way or the other. If
someone can figure out the type magic, we could fix it regardless.

Thanks much for reading! Regardless, the code was fun to write, and I
hope it will be useful to someone other than me.

Bart Massey
bart at cs.pdx.edu




More information about the Libraries mailing list