Date: Fri, 12 Mar 1999 15:31:55 GMT
Message-Id: <199903121531.PAA03531@toy.william.bogus>
From: William Chesters <williamc@dai.ed.ac.uk>
To: caml-list@inria.fr
Subject: Re: ocaml 2.02 bug: curried printf
In-Reply-To: <19990312160017.60444@pauillac.inria.fr>
<19990312160017.60444@pauillac.inria.fr>
Xavier Leroy writes:
> The behavior of the *printf functions when partially applied
> has always been a bit strange even before 2.02: [...]
Ooooh yes, I never noticed that ...
> 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?
The change in behaviour was a nuisance to me (and I now have a module
called Printf201!). In spite of that I'd be happy to stick with the
new semantics if it's more efficient. I say that becase I believe the
reason I used constructs like
concat " " (Array.map (sprintf "...") xs)
, for generating C code and string representations of complex objects,
was precisely because of the lack of extensible string buffers. With
Buffer available I would be more likely to use a `for' loop with
`bprintf' (or indeed `Format.bprintf').
This archive was generated by hypermail 2b29 : Sun Jan 02 2000 - 11:58:21 MET