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 MAA16478; Mon, 19 Jul 2004 12:00:12 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id MAA16816; Mon, 19 Jul 2004 12:00:11 +0200 (MET DST) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by concorde.inria.fr (8.12.10/8.12.10) with ESMTP id i6JA03SH030964; Mon, 19 Jul 2004 12:00:03 +0200 Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id MAA16411; Mon, 19 Jul 2004 12:00:03 +0200 (MET DST) From: Pierre Weis Message-Id: <200407191000.MAA16411@pauillac.inria.fr> Subject: Re: [Caml-list] kprintf with user formatters In-Reply-To: <20040716171444.GC741@fichte.ai.univie.ac.at> from Markus Mottl at "Jul 16, 104 07:14:44 pm" To: markus@oefai.at (Markus Mottl) Date: Mon, 19 Jul 2004 12:00:03 +0200 (MET DST) Cc: pierre.weis@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 concorde with ID 40FB9BA3.001 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 printf:01 printf:01 scanf:01 unsound:01 unsound:01 marshall:01 unwieldy:01 fprintf:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk [...] > Well, I suppose you don't want to imply that I should refrain from using > modules Printf and Format? They are full of Obj.magic! I certainly not want to imply that you should refrain from using Printf, Format, Scanf, and also the ocaml interactive system, given that they all use Obj.magic. However, all those uses of Obj.magic have a strong theoretical justification. In the best case they have been proved to be perfectly sound. In any case, we certainly never have a proof that some of those Obj.magic uses can lead to a wrong value (as a closure supposed to have type unit would be). > I have definitely given it some thought whether there could be some > kind of unsound use of return values, but I didn't find anything, > because unit-values are always ignored. Thank you for given some thought about unsound use of Obj.magic on the compiler. If you ever discover one (out of Marshall), please let us know, we will be glad to modify it :) However, I'm glad that you ``didn't find anything''. I should say that this is not, as you guessed, ``because unit-values are always ignored'': the reason is more likely to be that we always have strong evidence that those Obj.magic occurrences are harmless and extremely hard to eliminate. > Any other solution I have seen so far is much more complicated: it either > requires the use of a preprocessor, thunking or the use of lazy values > (I had already used them before - very unwieldy) or forces unnecessary > computations even if some action at the current log level shouldn't > be logged. > > The only sufficiently efficient, elegant and safe solution would be to > introduce some kind of flag into the fprintf_out function in Printf so > that it doesn't call string conversion functions. Or provide a dummy > function that just parses the format string and removes arguments. > This way a zprintf-function could be put into the interface. Once more you do not solve the problem of arguments useless evaluation. I'm convinced that the more elegant way is to introduce some support for logging into the system. 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