Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
[Caml-list] kprintf with user formatters
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2004-07-16 (17:44)
From: Markus Mottl <markus@o...>
Subject: Re: [Caml-list] kprintf with user formatters
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

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


Markus Mottl

To unsubscribe, mail Archives:
Bug reports: FAQ:
Beginner's list: