Browse thread
ocaml 2.02 bug: curried printf
[
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: | -- (:) |
| From: | John Prevost <prevost@m...> |
| Subject: | Re: another approach to sprintf (Re: ocaml 2.02 bug: curried printf) |
Xavier Leroy <Xavier.Leroy@inria.fr> writes: > It's a cute trick. One drawback is that the format is not a character > string, but needs to be expressed using special functions and infix > operators. On the other hand, it doesn't need the special > typechecking rules for format strings that we have in OCaml. > > With this special typechecking rules, I don't think Danvy's "partially > evaluated" printf is any safer than OCaml's "interpreted" printf. > > Also, it doesn't solve (nor makes any worse) the issues with partial > application of printf and friends that we discussed before. It does, however, mean that people can extend the set of patterns that can be used in printf in a more palatable way than the %a mechanism. Especially with neat things like Danvy's "lis" combinator. It also allows me to take two formats and concatenate them, like this: let foo = int $ lit " " $ int $ string let bar = lis int $ lit "!" let zum = foo $ bar which you can't do with O'Caml's format strings. (I tried to hack something to do this once, using Obj.magic as the Printf module does. I wasn't able to come up with anything, but I may be able to now that I've had more experience looking at things like Danvy's printf.) John.