Text.Printf replacement?

[Christopher Done]

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
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20130906/940e7aa0/attachment.htm>