another approach to sprintf (Re: ocaml 2.02 bug: curried printf)

From: Eijiro Sumii (sumii@venus.is.s.u-tokyo.ac.jp)
Date: Fri Mar 19 1999 - 09:47:20 MET


To: caml-list@inria.fr
Subject: another approach to sprintf (Re: ocaml 2.02 bug: curried printf)
In-Reply-To: Your message of "Fri, 12 Mar 1999 16:00:17 +0100"
        <19990312160017.60444@pauillac.inria.fr>
Message-Id: <19990319174720-10695P.sumii@harp.is.s.u-tokyo.ac.jp>
Date: Fri, 19 Mar 1999 17:47:20 +0900
From: Eijiro Sumii <sumii@venus.is.s.u-tokyo.ac.jp>

Hello,

(Excuse me for changing the subject and providing no French
version...)

I don't know very much about *printf in ocaml, but how about Olivier
Danvy's approach to sprintf (http://www.brics.dk/RS/98/12/index.html)?
It seems safer and faster than ordinary "interpretive" approach. I'd
like to hear what do you (I mean, readers of this mailing list) think
about it.

> Subject: Re: ocaml 2.02 bug: curried printf
> From: Xavier Leroy <Xavier.Leroy@inria.fr>
> Date: Fri, 12 Mar 1999 16:00:17 +0100
...
> We can go back to the 2.01 implementation of sprintf, of course, but
> it's less efficient than the one based on extensible buffers, and also
> prevents interesting code sharing between sprintf and bprintf.
>
> The alternative is to keep a buffer-based sprintf that is efficient
> and consistent with printf ("consistent" in the sense of "as weird as"),
> but is not really usable in partial application contexts.
>
> Any opinions?

// Eijiro Sumii <sumii@yl.is.s.u-tokyo.ac.jp>
//
// Kobayashi Laboratory, Department of Information Science,
// Graduate School of Science, University of Tokyo



This archive was generated by hypermail 2b29 : Sun Jan 02 2000 - 11:58:21 MET