Browse thread
[Caml-list] kprintf with user formatters
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: | 2004-07-19 (09:17) |
From: | Pierre Weis <pierre.weis@i...> |
Subject: | Re: [Caml-list] kprintf with user formatters |
[...] > I also use the same kind of trick in practice, with a little > refinement to avoid building the closure. I introduce higher-order > functions such as > > val if_debug : ('a -> unit) -> 'a -> unit > > which behaves like application when the debug flag is on (and does > nothing otherwise). Then you can simply write [...] This does not solve the problem of evaluating the argument(s) of the logging application. Consider the example I gave: > log 2 (fun () -> > eprintf "Argument 1 is hard to compute %d\n" (ackermann x x)) Your solution would lead to if_debug2 eprintf "Argument 1 is hard to compute %d\n" (ackermann x x) which wastes is too much computing power when the debug turn out to be off. This is not purely rethorical: I already encountered this problem in practice (the runtime with logging output turned to off was still so slow that it was impossible to compute the result in a comfortable time delay; I was obliged to turn the logging facility to the (fun () -> ...) style to continue the development). The solution is the same as for the previous request (``not converting the arguments to strings before discarding the result''): use a devoted construct that would change the semantics for this common but arguably very specific case. 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