Re: Text.Printf replacement?

Doh. How did I miss printf-mauke when I was digging through Hackage? Looks like I've duplicated some work. I think with the extensible-printf approach, bonus PrintfArg instances should exist in the respective packages (bytestring, ffi, etc) rather than being centralized in Text.Printf. If we end up using extensible-printf, someone should put those patches in place. --Bart On Fri, Sep 6, 2013 at 11:10 AM, Christopher Done wrote:

FWIW printf-mauke has a TH quoter: http://hackage.haskell.org/packages/archive/printf-mauke/0.5.1/doc/html/Text...

On 6 September 2013 20:05, Bart Massey wrote:

...

I'd prefer strongly typed formatting too, although I'm not sure I'm smart enough to learn the cool-looking package you point to :-). However, we are unlikely to remove Text.Printf as a formatting option for those who prefer "stringly typed" (nice pun!). An option I'd thought about is to actually process the format string using Template Haskell :-). It would make the calling convention a little syntactically-different, I guess, but would let me use my comfortable old printf format strings and still get static typechecking.

In any case, in my motivating application (http://github.com/BartMassey/hseq -- yes, it's the Haskell sequence) I am forced by the existing spec to expose printf format strings to the user. Bleah, but there I am.

--Bart

On Fri, Sep 6, 2013 at 4:48 AM, Christopher Done wrote:

...

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 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@cs.pdx.edu

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries