[Caml-list] Vagaries of Printf variants

[Caml-list] Vagaries of Printf variants

[David Allsopp]

Given:

let f fmt = Printf.printf fmt;;

[f] will have type ('a, out_channel, unit, unit) format4

Given:

let f fmt = Printf.ksprintf print_string fmt

[f] will have type ('a, unit, string, unit) format4

They do exactly the same thing (at least in terms of side effects) - what's
the fundamental reason for having to suffer their having incompatible format
types? It becomes excessively irritating when trying to switch between
different formatters (as a given format string cannot be used in a way in
which it appears to have more than one type, obviously), but I'm sure
there's a reason for its being that way!


David

Re: [Caml-list] Vagaries of Printf variants

[Daniel Bünzli]

Le lundi, 27 octobre 2014 à 18:56, David Allsopp a écrit :
> but I'm sure there's a reason for its being that way!

You may be interested in reading this:

http://gallium.inria.fr/blog/format6/

Daniel

P.S. If you are using formatters the problem is less acute. Nowadays you can simply define formatters for each of your types with:

pp : Format.formatter -> t -> unit  

and a to_string function is one `Format.asprintf "%a" pp` away.

RE: [Caml-list] Vagaries of Printf variants

[David Allsopp]

Daniel Bünzli wrote:
> Le lundi, 27 octobre 2014 à 18:56, David Allsopp a écrit :
> > but I'm sure there's a reason for its being that way!
> 
> You may be interested in reading this:
> 
> http://gallium.inria.fr/blog/format6/

Thanks, that is enlightening! I guess the thing that gets "in the way" is the design decision to make %a operate on the printf-behaviour (i.e. for fprintf, it writes to a channel, for bprintf it writes to a buffer) rather than making %a and %t *always* return a string.

> P.S. If you are using formatters the problem is less acute. Nowadays you
> can simply define formatters for each of your types with:
> 
> pp : Format.formatter -> t -> unit
> 
> and a to_string function is one `Format.asprintf "%a" pp` away.

I was abusing terminology - by formatters I meant printf functions i.e. selecting between ikfprintf, kfprintf, etc. in the same functions.

I haven't looked at the 4.02 sources, but for what I'm doing in 4.01, what would actually be useful would be if Printf.mkprintf were public so that I could supply an alternate function for output_string (i.e. allow Printf.printf to proceed entirely as normal but do something ever-so-slightly different with the final result - and with a different format6 from using ksprintf).


David

Re: [Caml-list] Vagaries of Printf variants

[Gabriel Scherer]

If you know from the start that you need this flexibility, the easiest
way is probably to use Printf.bprintf from the start, which is
reasonably efficient and flexible (or write your fprintf-formats with
%s rather than %a).

If you specifically need to convert code that uses (f)printf with
minimal changes, you have the problem that your %a/%t functions work
with out_channel, not strings. The simplest way out is probably to use
Unix.pipe (which is available on Windows) to create an out_channel
that you write into and read back the content as a string.

On Tue, Oct 28, 2014 at 10:04 AM, David Allsopp <dra-news@metastack.com> wrote:
> Daniel Bünzli wrote:
>> Le lundi, 27 octobre 2014 à 18:56, David Allsopp a écrit :
>> > but I'm sure there's a reason for its being that way!
>>
>> You may be interested in reading this:
>>
>> http://gallium.inria.fr/blog/format6/
>
> Thanks, that is enlightening! I guess the thing that gets "in the way" is the design decision to make %a operate on the printf-behaviour (i.e. for fprintf, it writes to a channel, for bprintf it writes to a buffer) rather than making %a and %t *always* return a string.
>
>> P.S. If you are using formatters the problem is less acute. Nowadays you
>> can simply define formatters for each of your types with:
>>
>> pp : Format.formatter -> t -> unit
>>
>> and a to_string function is one `Format.asprintf "%a" pp` away.
>
> I was abusing terminology - by formatters I meant printf functions i.e. selecting between ikfprintf, kfprintf, etc. in the same functions.
>
> I haven't looked at the 4.02 sources, but for what I'm doing in 4.01, what would actually be useful would be if Printf.mkprintf were public so that I could supply an alternate function for output_string (i.e. allow Printf.printf to proceed entirely as normal but do something ever-so-slightly different with the final result - and with a different format6 from using ksprintf).
>
>
> David
>
> --
> Caml-list mailing list.  Subscription management and archives:
> https://sympa.inria.fr/sympa/arc/caml-list
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs

RE: [Caml-list] Vagaries of Printf variants

[David Allsopp]

Gabriel Scherer wrote:
> If you know from the start that you need this flexibility, the easiest way
> is probably to use Printf.bprintf from the start, which is reasonably
> efficient and flexible (or write your fprintf-formats with %s rather than
> %a).

Alas, I'm contributing, rather than authoring from scratch!

> If you specifically need to convert code that uses (f)printf with minimal
> changes, you have the problem that your %a/%t functions work with
> out_channel, not strings. The simplest way out is probably to use
> Unix.pipe (which is available on Windows) to create an out_channel that
> you write into and read back the content as a string.

That is a very cunning idea, thank you!


David

Re: [Caml-list] <DKIM> Re: Vagaries of Printf variants

[Pierre Chambart]

On 28/10/2014 10:19, Gabriel Scherer wrote:
> If you know from the start that you need this flexibility, the easiest
> way is probably to use Printf.bprintf from the start, which is
> reasonably efficient and flexible (or write your fprintf-formats with
> %s rather than %a).
>
> If you specifically need to convert code that uses (f)printf with
> minimal changes, you have the problem that your %a/%t functions work
> with out_channel, not strings. The simplest way out is probably to use
> Unix.pipe (which is available on Windows) to create an out_channel
> that you write into and read back the content as a string.
I wouldn't recommend something like that: you are exposing yourself to
deadlocks.
If you are not carefull, your write will reach the OS-defined limit to
the pipe size, and
will block the process until someone reads the pipe. So you will need
another
thread to read the channel...
-- 
Pierre

RE: [Caml-list] <DKIM> Re: Vagaries of Printf variants

[David Allsopp]

Pierre Chambart wrote:
> On 28/10/2014 10:19, Gabriel Scherer wrote:
> > If you know from the start that you need this flexibility, the easiest
> > way is probably to use Printf.bprintf from the start, which is
> > reasonably efficient and flexible (or write your fprintf-formats with
> > %s rather than %a).
> >
> > If you specifically need to convert code that uses (f)printf with
> > minimal changes, you have the problem that your %a/%t functions work
> > with out_channel, not strings. The simplest way out is probably to use
> > Unix.pipe (which is available on Windows) to create an out_channel
> > that you write into and read back the content as a string.
> I wouldn't recommend something like that: you are exposing yourself to
> deadlocks.
> If you are not carefull, your write will reach the OS-defined limit to the
> pipe size, and will block the process until someone reads the pipe. So you
> will need another thread to read the channel...

That's a good point, thanks. Though my use-case here is strictly for console output, where blowing the minimum 4K allocated to the pipe would be unlikely - however, it can be easily solved with a C thread (rather than the weight of an OCaml thread).


David