Re: [Caml-list] kprintf with user formatters

[Markus Mottl <markus@oefai.at>]

On Fri, 16 Jul 2004, Pierre Weis wrote:
> 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))

I have used thunks (and lazy values) before, but they are usually
syntactically ugly.

Instead of:

  log (fun () -> sprintf "%d" n)

I'd rather want to write

  log "%d" n

without having the log function compute a string from an integer if this
is not necessary.  Would this really be so difficult to support?

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

Well, you have to create a thunk, but this cost is acceptable to me.
I just don't want to clutter my code with thunks + additional sprintf
statements.

> Moreover, this solution is general enough to accomodate threads,
> side effects, or whatever.

You always need mutexes if you want to prevent that your output gets
messed up by multiple threads.

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

It's rather the other way round: people using format strings may get
the wrong idea that arguments are not converted if there is no output.

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

I don't think it is necessary or even useful to introduce new keywords.

A customized, beautiful solution would be possible with camlp4, thunks
solve the problem semantically, but look ugly, and some support for a
kind of zprintf would be ideal :-)

Regards,
Markus

-- 
Markus Mottl          http://www.oefai.at/~markus          markus@oefai.at

-------------------
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