> On Thu, Jul 15, 2004 at 03:45:30PM +0200, Markus Mottl wrote:
> > On Thu, 15 Jul 2004, Basile Starynkevitch [local] wrote:
> > > I don't understand what this zprintf function should be,
> > 
> > It should parse the format string, and ignore format arguments following
> > it.
> 
> let zprintf fmt = Printf.kprintf (fun _ -> ()) fmt
> should be ok.
> 
> But I think that the format string should not even be parsed. I've got
> no solution (except the one below) to this!

Well, you just need to think functionnally!

If I understand properly:

- you want to skip the runtime time penalty of formatting the
arguments to string before discarding the result,
- you even want not to parse the format string,
- ideally you also want NOT TO EVALUATE the reminding arguments of
your printf call ?

Hmm, this sounds extremely lazy to me; so this suggests thunk
programming; hey, we have that in the language, so let's go!

let log level thunk =
 if may_log level then thunk ();;

...

 log 2 (fun () ->
   eprintf "Argument 1 is hard to compute %d\n" (ackermann x x))

That's the way we use to log in the OcamlP3l compiler: we've got no
runtime penalty if there is no necessity to log. Moreover, this
solution is general enough to accomodate threads, side effects, or
whatever.

To me the (fun () -> ) additional verbosity is not so bad: it clearly
emphasizes that nothing at all is evaluated when logging is unnecessary.

To go beyond that, we would need some help from the language that
would offer some provision for debugging from a special debug keyword,
semantically reminiscent to lazy and assert (as a kind of combined
semantics of both constructs). A compiler flag would then
automatically remove the debugging code (as is done for assert with
the -noassert flag) and the compiler will automatically insert the
(fun () -> ) as it already does in the case of lazy ...

[...]
> Actually, I more and more hate printf, both in C and in Ocaml. I
> really believe it is a nightmare.

Could you elaborate a bit ? We worked hard to provide a clean fully
typed interface to printf and, well ... we like using it :)

We may have missed the point that makes your printf experience ``a
nightmare'', and having information on that could be helpful to
improve the implementation. 

> A possible suggestion might be to 
>   add a StopPrintf exception to Printf
> and
>   add a tryprintf function to Printf, which takes a prologue function
> as an argument. If the prologue raises an exception, no formatting
> occur;  otherwise, tryprintf works like kprintf

I don't think the problem is in printf. The problem is in the way you
call printf (no printf variant could prevent evaluating the format
string and evaluating the arguments of its call: this is mandatory due
to the semantics of the language).

Best regards,

Pierre Weis

INRIA, Projet Cristal, Pierre.Weis@inria.fr, http://pauillac.inria.fr/~weis/


-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners