>>>>> "jm" == Jérôme Marant <jerome.marant@free.fr> writes:

    >> Even if you want to do things at runtime, you can compile the
    >> default string at compile-time, and then you know the type to
    >> expect.

    jm>   This is true with the current implementation of printf in
    jm> the Printf module. But this would be wrong if you consider
    jm> parameter reordering in the C printf (the printf manual page
    jm> gives enough good explainations).

    jm>   I've been giving the following example for quite long now:
    jm> languages do not always order words the same way. So,
    jm> sometimes, you need to reorder parameters in translated
    jm> strings in order to get a correct syntax in the targeted
    jm> language. With printf, you can do it this way:

    jm>   fr: " %s %d"
  
    jm>   string -> int

    jm>   de: " %2$s %1$d"

    jm>   int -> string

    jm>   This example shows that if you want a full featured
    jm> internationalisation, you cannot state that "you know the type
    jm> you expect" since you will only determine it at run-time.

Actually, this is not a counter-example, it's just a place where the
current O'Caml format typing rules are insufficient.  In this case,
there's a simple reason the two types are different: the formats are
incompatible.  What you want is:

fr: " %d %s"
de: " %2$s %1$d"

in your model, which produces two formats of type int -> string which
can be interchanged.  If you only "know the type at runtime", it means
you have a type error.

Just to add to things: if you use a module as a message catalog with
combinator formats, argument re-ordering is based on a wrapper
function:

let fr k s     = (lit " " $$ int $$ lit " " $$ str) k s
let de k s a b = (lit " " $$ str $$ lit " " $$ int) k s a b

(One of course should do something to make this at least a little
cleaner, though.  Including one argument to defeat the polymorphism
restriction is one thing, but putting two arguments in is more of a
pain.)

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