From mboxrd@z Thu Jan  1 00:00:00 1970
Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id TAA05311 for caml-redistribution; Fri, 19 Mar 1999 19:25:59 +0100 (MET)
Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id JAA12823 for <caml-list@pauillac.inria.fr>; Fri, 19 Mar 1999 09:47:30 +0100 (MET)
Received: from venus.is.s.u-tokyo.ac.jp (venus.is.s.u-tokyo.ac.jp [133.11.12.9])
	by nez-perce.inria.fr (8.8.7/8.8.7) with ESMTP id JAA23363
	for <caml-list@inria.fr>; Fri, 19 Mar 1999 09:47:28 +0100 (MET)
Received: from harp (harp [133.11.12.2])
	by venus.is.s.u-tokyo.ac.jp (8.9.3/3.7W) with ESMTP id RAA19696
	for <caml-list@inria.fr>; Fri, 19 Mar 1999 17:47:20 +0900 (JST)
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>
References: <19990312160017.60444@pauillac.inria.fr>
X-Mailer: Mew version 1.93 on Emacs 19.28 / Mule 2.3 (SUETSUMUHANA)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
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>
X-Dispatcher: imput version 980905(IM100)
Sender: weis

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