Text.Printf replacement?

[Bart Massey]

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 <chrisdone at gmail.com> 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 <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
>
>