[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: | 2002-05-02 (17:39) |
From: | John Prevost <visigoth@c...> |
Subject: | Re: [Caml-list] printf and scanf |
>>>>> "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