Text.Printf replacement?

[Christopher Done]

I prefer a well-typed extensible combinator approach like:

http://chrisdone.com/holey-format/Text-Format.html

than the stringly typed approach of printf.


On 6 September 2013 04:16, Bart Massey <bart at cs.pdx.edu> wrote:

> 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
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20130906/eacc2c2b/attachment.htm>