From mboxrd@z Thu Jan  1 00:00:00 1970
Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id LAA13519; Mon, 19 Jul 2004 11:17:59 +0200 (MET DST)
X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f
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 LAA12114; Mon, 19 Jul 2004 11:17:58 +0200 (MET DST)
Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35])
	by nez-perce.inria.fr (8.12.10/8.12.10) with ESMTP id i6J9HvEV024124;
	Mon, 19 Jul 2004 11:17:57 +0200
Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id LAA13543; Mon, 19 Jul 2004 11:17:56 +0200 (MET DST)
From: Pierre Weis <pierre.weis@inria.fr>
Message-Id: <200407190917.LAA13543@pauillac.inria.fr>
Subject: Re: [Caml-list] kprintf with user formatters
In-Reply-To: <16631.32784.526557.747099@gargle.gargle.HOWL> from Jean-Christophe Filliatre at "Jul 16, 104 09:13:20 am"
To: Jean-Christophe.Filliatre@lri.fr
Date: Mon, 19 Jul 2004 11:17:56 +0200 (MET DST)
Cc: pierre.weis@inria.fr, basile.starynkevitch@inria.fr, caml-list@inria.fr
X-Mailer: ELM [version 2.4ME+ PL28 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-Miltered: at nez-perce with ID 40FB91C5.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)!
X-Loop: caml-list@inria.fr
X-Spam: no; 0.00; pierre:01 weis:01 pierre:01 weis:01 caml-list:01 kprintf:01 formatters:01 higher-order:01 val:01 eprintf:01 ackermann:01 eprintf:01 ackermann:01 wastes:01 runtime:01 
Sender: owner-caml-list@pauillac.inria.fr
Precedence: bulk

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