[...]
> 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