Text.Printf replacement?

[Bart Massey]

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 <chrisdone at gmail.com> wrote:
> FWIW printf-mauke has a TH quoter:
> http://hackage.haskell.org/packages/archive/printf-mauke/0.5.1/doc/html/Text-Printf-Mauke-TH.html
>
>
> On 6 September 2013 20:05, Bart Massey <bart at cs.pdx.edu> 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 <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
>> >
>> >
>
>