From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by sympa.inria.fr (Postfix) with ESMTPS id 576B47ED7A for ; Thu, 20 Sep 2012 23:04:33 +0200 (CEST) Received-SPF: None (mail1-smtp-roc.national.inria.fr: no sender authenticity information available from domain of Anil@recoil.org) identity=pra; client-ip=89.16.177.154; receiver=mail1-smtp-roc.national.inria.fr; envelope-from="avsm@dark.recoil.org"; x-sender="Anil@recoil.org"; x-conformance=sidf_compatible Received-SPF: None (mail1-smtp-roc.national.inria.fr: no sender authenticity information available from domain of avsm@dark.recoil.org) identity=mailfrom; client-ip=89.16.177.154; receiver=mail1-smtp-roc.national.inria.fr; envelope-from="avsm@dark.recoil.org"; x-sender="avsm@dark.recoil.org"; x-conformance=sidf_compatible Received-SPF: None (mail1-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@dark.recoil.org) identity=helo; client-ip=89.16.177.154; receiver=mail1-smtp-roc.national.inria.fr; envelope-from="avsm@dark.recoil.org"; x-sender="postmaster@dark.recoil.org"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiYCAIKDW1BZELGagWdsb2JhbABFvWQBARYmJ4IgAQEFOjMMEAsYLhQNPBOHcQMTsE8NiVOKOmKGQgOUD4FUAYEUigOHcg X-IronPort-AV: E=Sophos;i="4.80,455,1344204000"; d="scan'208";a="174026056" Received: from recoil.dh.bytemark.co.uk (HELO dark.recoil.org) ([89.16.177.154]) by mail1-smtp-roc.national.inria.fr with SMTP; 20 Sep 2012 23:04:32 +0200 Received: (qmail 10190 invoked by uid 10000); 20 Sep 2012 21:04:31 -0000 Date: Thu, 20 Sep 2012 22:04:31 +0100 From: Anil Madhavapeddy To: Wojciech Meyer Cc: Gabriel Scherer , caml users Message-ID: <20120920210431.GI22767@dark.recoil.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [Caml-list] working %.pp.ml target with ocamfind/ocamlbuild On Sun, Sep 09, 2012 at 05:29:53PM +0100, Wojciech Meyer wrote: > Gabriel Scherer writes: > > > This is useful for debugging purposes, and for some (minor) modes of > > use of Camlp4. However, for most Camlp4 development, this has the > > severe downside of losing the location information of the original > > file, if I understand correctly. This means that you don't want to use > > it as a transparent step towards compilation, but only in exceptional > > situations where the developers will re-edit the output code. > > I think I've to say I disagree it's not useful, when I'm developing a > syntax extension on top of Camlp4 I really want to see the generated > code. Moreover to understand some of the more complicated syntax > extensions like type_conv, deriving, FoldGenerator I need to look at the > expanded code to understand how to use it - last time I hit the same > problem it was actually 'deriving-ocsigen' when I needed to implement my > own Show module - it's just much faster to see what's being generated > for the usual case, then trying to figure out from the recipe in the > documentation. Otherwise for bootstrapping purposes, you might want to > pre-generate some code too and put into the repository. The %.pp.ml rule is really essential for day-to-day development too. Since camlp4 cannot generate ocamldoc comments, it's often easier to just dump the .pp.ml output and inspect the code directly, rather than root around figuring out what the code generator modules are doing. This is less of an issue with well-established extensions such as sexplib, but useful when learning new ones such as the Lwt one (which has some odd corner cases such as the >> bind precedence). -- Anil Madhavapeddy http://anil.recoil.org