Martin, in the meantime, you can use Extlib's (Std.dump : 'a -> string) function, which is also integrated into Batteries. `dump` does not require any modification to the compiler or toolchain.
For those that are not familiar with it, 'dump' uses the low-level representation of OCaml values to print a sensible string representing a value. As it only uses information that is available at runtime, it is much less precise that Jeremie's printer, as for example None, false, [] and 0 will all be printed as 0 (they have the same runtime representation). Of course, the "right" way to print/marshal data without changing the language is to build a printer for your type from printer combinators. Such combinators are available for example: - in Jane Street Core library ( a Sexpable interface in each datatype module ) - in Xavier Clerc's Kaputt testing framework : http://kaputt.x9c.fr/distrib/api/Utils.html You can also use metaprogramming (.. camlp4) to generate printer functions from datatypes description automatically, using such combinators. See: - Markus Mottl's 'type-conv': http://hg.ocaml.info/release/type-conv - Jeremy Yallop's 'deriving': http://code.google.com/p/deriving/ Of course, printing values magically is still easier: you don't have to build the printer yourself, passing subtype printers when necessary, etc. I think Std.dump is reasonable for quick hacks or debugging usage. On Thu, Dec 8, 2011 at 7:20 PM, Martin Jambon <[email protected]> wrote: > On 12/08/2011 04:00 AM, Romain Bardou wrote: >>>> 2) Could you imagine to generalize it to Format.formatter or to >>>> out_channel (without creating a string and concatenating)? Romain Bardou >>>> add in the mantis tracker (I can't give you the bugtracking number since >>>> mantis "is currently offline for maintenance") a feature wish for a new >>>> conversion specification that can print anything. Do you think you can >>>> fulfill is dream? >> >> Here is the feature request I proposed: >> >> http://caml.inria.fr/mantis/view.php?id=4956 >> >> Here is the response by Pierre Weis: >> >> "This is a major feature wish that requires careful thinking and a lot >> of work! >> >> Furthermore, we would not have a completely satisfactory solution in the >> end (due to this <poly> catch all case that tend to propagate, as far as >> you use polymorphic functions). The correct solution to get this feature >> in its full glory is a major modification of the type system along the >> lines of G'Caml. > > The feature we want is exactly Jeremie's "hack" (his words). We need > this feature for debugging and displaying data in log files. This kind > of data is almost never polymorphic, so there is no practical issue > here. Also we don't need a standardized output format. However we would > often like to truncate the data to a reasonable size. > > I understand that this feature could be replaced in the future by a more > complete solution, but we would be happy if it were provided as an > "experimental extension" of OCaml. > > > Martin > >> In short, a natural feature wish in a strongly typed polymorphic >> language; we had it in mind for decades; unfortunately, we are not yet >> ready to offer it, even in the rather limited extent you proposed." >> >> In other words: what you did is awesome but I'm not sure that it will be >> added in the trunk :( >> >> Cheers, >> > > > -- > Caml-list mailing list. Subscription management and archives: > https://sympa-roc.inria.fr/wws/info/caml-list > Beginner's list: http://groups.yahoo.com/group/ocaml_beginners > Bug reports: http://caml.inria.fr/bin/caml-bugs > -- Caml-list mailing list. Subscription management and archives: https://sympa-roc.inria.fr/wws/info/caml-list Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
