[Caml-list] printf and scanf

[Caml-list] printf and scanf

[Francois-Rene Rideau]

On Tue, 30 Apr 2002 12:22:49 +0000 (UTC), frappo wrote:
> Unfortunately, Danvy's encoding relies on the fact that
> the format specification is *not* a string.
Isn't camlp4 the obvious solution to this problem?
Format strings could "just" be processed at compile-time
by a camlp4 extension that produces a Danvy-style encoding
out of the format string.
Runtime processing of format string is more problematic,
but who needs that, anyway? Instead of concatenating format strings,
you'd directly use Danvy-style combinators.

Just my 2.e-7 kg of gold worth.

[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ]
[  TUNES project for a Free Reflective Computing System  | http://tunes.org  ]
Mathematicians are like Frenchmen: whatever you say to them they
translate into their own language, and forthwith it is something
entirely different.
		-- Johann Wolfgang von Goethe
-------------------
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

Re: [Caml-list] printf and scanf

[Jérôme Marant]

Francois-Rene Rideau <fare@tunes.org> writes:

> Runtime processing of format string is more problematic,
> but who needs that, anyway? Instead of concatenating format strings,

  There are some cases where you may know the format string
  only at runtime; the most obvious example is internationalization
  through something like gettext.

  Cheers,

-- 
Jérôme Marant

http://marant.org
              
-------------------
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

Re: [Caml-list] printf and scanf

[Francois Pottier]

Fare wrote:

> Isn't camlp4 the obvious solution to this problem?
> Format strings could "just" be processed at compile-time
> by a camlp4 extension that produces a Danvy-style encoding
> out of the format string.

Sounds reasonable, except I would perhaps prefer to expose the
underlying combinators everywhere (rather than provide syntactic
sugar for the simple cases and require direct use of combinators
in more complex cases, leading to two apparently unrelated
languages).

-- 
François Pottier
Francois.Pottier@inria.fr
http://pauillac.inria.fr/~fpottier/
-------------------
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

Re: [Caml-list] printf and scanf

[Jérôme Marant]

John Prevost <visigoth@cs.cmu.edu> writes:

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

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

  Well, it was wrong indeed and Pixel gave the reasons.

  Regards,

-- 
Jérôme Marant

http://marant.org
              
-------------------
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

Re: [Caml-list] printf and scanf

[Jérôme Marant]

Pixel <pixel@mandrakesoft.com> writes:

> this only shows that " %2$s %1$d" is not a valid translation of " %s %d",
> since they do not have the same type, and would fail at runtime (using this in
> C would give you a segfault).
>
> " %2$d %1$s" with type "string -> int" is a valid translation of " %s %d"
>
> this means that not checking the translations could lead to a hole in the type
> system, and so printf must be prepared to detect type errors (which it
> currently does :)

  Hmm, you're correct, I was mistaken. Perhaps I should reead the sprintf manpage.
  But it doesn't have the feature anyway.

  Regards,

-- 
Jérôme Marant

http://marant.org
              
-------------------
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

Re: [Caml-list] printf and scanf

[John Prevost]

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

Re: [Caml-list] printf and scanf

[Pixel]

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

> I've been giving the following example for quite long now: languages
> do not always order words the same way. So, sometimes, you need to
> reorder parameters in translated strings in order to get a correct
> syntax in the targeted language. With printf, you can do it this way:
> 
> fr: " %s %d"
> 
> string -> int
> 
> de: " %2$s %1$d"
> 
> int -> string
> 
> This example shows that if you want a full featured internationalisation,
> you cannot state that "you know the type you expect" since you will only
> determine it at run-time.

this only shows that " %2$s %1$d" is not a valid translation of " %s %d",
since they do not have the same type, and would fail at runtime (using this in
C would give you a segfault).

" %2$d %1$s" with type "string -> int" is a valid translation of " %s %d"

this means that not checking the translations could lead to a hole in the type
system, and so printf must be prepared to detect type errors (which it
currently does :)
-------------------
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

Re: [Caml-list] printf and scanf

[Jérôme Marant]

On Wed, May 01, 2002 at 08:00:53PM +0200, Francois-Rene Rideau wrote:
> Jerome Marant wrote:
>   There are some cases where you may know the format string
>   only at runtime; the most obvious example is internationalization
>   through something like gettext.
> 
> Rather, the format strings are known at compile-time,
> but you don't know which string will be used.
> So you can precompile all strings, and
> select the right formatter at run-time.

  I'm sorry, what do call "formatter"? Is it the format string or the
  formating function?

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

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

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

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

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

  int -> string

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

  Cheers,

-- 
Jérôme Marant
-------------------
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

[Caml-list] printf and scanf

[Francois-Rene Rideau]

Jerome Marant wrote:
  There are some cases where you may know the format string
  only at runtime; the most obvious example is internationalization
  through something like gettext.

Rather, the format strings are known at compile-time,
but you don't know which string will be used.
So you can precompile all strings, and
select the right formatter at run-time.

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.
Switching strings can then be done in a type-safe way: throw an exception
if the type of the replacement string's compiled printer doesn't match.
You'll need this type of mechanism, anyway.

[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ]
[  TUNES project for a Free Reflective Computing System  | http://tunes.org  ]
Guns & bullets don't kill people -- blood loss and organ damage kills people.
-------------------
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