From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by walapai.inria.fr (8.13.6/8.13.6) with ESMTP id pB8Ldrce009280 for ; Thu, 8 Dec 2011 22:39:53 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArEBAFUu4U5KfVI0imdsb2JhbAApGpo8kCYIIgEBAQoJDQcSBiGBcgEBAQQSAhMZARsSCwEDDAYFCw0NISIBEQEFAQoSBhMSCQeHbSOaZAqLZIJrhD89iHECBQyDa4dEBJRrjXA9g3o X-IronPort-AV: E=Sophos;i="4.71,321,1320620400"; d="scan'208";a="122659027" Received: from mail-ww0-f52.google.com ([74.125.82.52]) by mail4-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-MD5; 08 Dec 2011 22:39:48 +0100 Received: by mail-ww0-f52.google.com with SMTP id dr12so4883589wgb.9 for ; Thu, 08 Dec 2011 13:39:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=BC8HLRei71FPBwKWTAJYl1oXpy+lzXX2xmfcN6R53/U=; b=O/qmzR7/haL9z+lQjPprwmLHILL0BohYzY2F3f7HlJl1M9EWecRgQcBnOfMm/u7poZ EVOdvlOBqtfzwUo518cTuyVXB2Hkr83ctDGgqQr0pgSZfNzsaDa3Cswr0I3L6BEi6Zd3 qXczcLnnMKDbpUjttS83X2aQiR4B+D9PC0Pgo= Received: by 10.227.206.78 with SMTP id ft14mr5095410wbb.24.1323380388275; Thu, 08 Dec 2011 13:39:48 -0800 (PST) MIME-Version: 1.0 Received: by 10.227.43.4 with HTTP; Thu, 8 Dec 2011 13:39:27 -0800 (PST) In-Reply-To: <4EE0FFDE.1050107@ens-lyon.org> References: <1323271707.32238.17.camel@arrakis> <4EDF9AAE.5050604@crans.org> <1323279292.32238.48.camel@arrakis> <4EE0A6C6.8040703@lri.fr> <4EE0FFDE.1050107@ens-lyon.org> From: Gabriel Scherer Date: Thu, 8 Dec 2011 22:39:27 +0100 Message-ID: To: Martin Jambon Cc: caml-list@inria.fr Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by walapai.inria.fr id pB8Ldrce009280 Subject: Re: [Caml-list] Generic printer patch 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 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 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 >