From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <5764c029b688c1c0d24a2e97cd764f@gmail.com> X-Original-To: caml-list@sympa.inria.fr Delivered-To: caml-list@sympa.inria.fr Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by sympa.inria.fr (Postfix) with ESMTPS id A86957EE6B for ; Wed, 27 Nov 2013 12:37:16 +0100 (CET) Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of 5764c029b688c1c0d24a2e97cd764f@gmail.com) identity=pra; client-ip=209.85.214.44; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="5764c029b688c1c0d24a2e97cd764f@gmail.com"; x-sender="5764c029b688c1c0d24a2e97cd764f@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of 5764c029b688c1c0d24a2e97cd764f@gmail.com designates 209.85.214.44 as permitted sender) identity=mailfrom; client-ip=209.85.214.44; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="5764c029b688c1c0d24a2e97cd764f@gmail.com"; x-sender="5764c029b688c1c0d24a2e97cd764f@gmail.com"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@mail-bk0-f44.google.com) identity=helo; client-ip=209.85.214.44; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="5764c029b688c1c0d24a2e97cd764f@gmail.com"; x-sender="postmaster@mail-bk0-f44.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmYDACXYlVLRVdYslGdsb2JhbABZghsEgSC7RIEfFg4BAQEBBwsLCRIqgiUBAQUMJgENARscAQEDDAYFCw0JFg8JAwIBAgEREQEFARwGDQEHAhUCh1MBAw8EAQijMYxZgwmERwoZJw1khygRAQEEDI4OaAeEMwOYFIZFiWFBgxeBPg X-IPAS-Result: AmYDACXYlVLRVdYslGdsb2JhbABZghsEgSC7RIEfFg4BAQEBBwsLCRIqgiUBAQUMJgENARscAQEDDAYFCw0JFg8JAwIBAgEREQEFARwGDQEHAhUCh1MBAw8EAQijMYxZgwmERwoZJw1khygRAQEEDI4OaAeEMwOYFIZFiWFBgxeBPg X-IronPort-AV: E=Sophos;i="4.93,781,1378850400"; d="scan'208";a="38198450" Received: from mail-bk0-f44.google.com ([209.85.214.44]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-SHA; 27 Nov 2013 12:37:16 +0100 Received: by mail-bk0-f44.google.com with SMTP id d7so3187584bkh.3 for ; Wed, 27 Nov 2013 03:37:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=lJ0z25cDARk+HP0w/uM3WnnVqvU4eu49YHEOm/P3N/s=; b=EMiKYXyhDD939jOwr+zqj6bbfu+Jzn/vz0Quo6zG018+7BHgJ9NT/3xfMHTz0fZScF W0MkuKSzrFQftlWyIjco41VtejYz6k5kfmNJgILitia57ffhNpheOxdoYClJVCsjLPYg NdpGnSMfG7d2q5qVDEjRERGXV2VjAWoSnbg0Vyx7wDVurDZYvJ4jp3t7tDJoRL2+/34s WCDseU44Jq6wWOx8Rd+7hYactspe//CuZ+Akw73ybNtHmFLTNiMVX3vPIpSCSg444GAX mEfB/YD6JeHxA3kGuSLhz6mrryzhEogvw5f7PQQlDIoSqkW6B/WFQPpcXlXOUYbOaIR9 dYnA== X-Received: by 10.204.232.145 with SMTP id ju17mr71422bkb.101.1385552235573; Wed, 27 Nov 2013 03:37:15 -0800 (PST) Received: from [172.27.6.192] ([213.106.240.92]) by mx.google.com with ESMTPSA id a4sm55153762bko.11.2013.11.27.03.37.14 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 27 Nov 2013 03:37:15 -0800 (PST) Message-ID: <5295D970.8090601@gmail.com> Date: Wed, 27 Nov 2013 11:37:20 +0000 From: Matej Kosik <5764c029b688c1c0d24a2e97cd764f@gmail.com> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20131005 Icedove/17.0.9 MIME-Version: 1.0 To: Gabriel Scherer CC: "caml-list@inria.fr" References: <529370C0.9020801@gmail.com> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Subject: Re: [Caml-list] [batteries] ... how to create (format) directives that do not take any arguments? On 25/11/13 16:27, Gabriel Scherer wrote: > Adding custom printing directives requires a syntax extension to > rewrite those directives into OCaml code. The built-in support for > magicly-typed formats in the OCaml language is not extensible (it is > complex enough as it is). > Batteries 1 used to provide such a syntax extension, but we > (re)discovered that users don't like syntax extensions: they make code > harder to compile/deploy, are controversial, and in the long run often > make our life harder instead of easier. Batteries 2 does not come with > any syntax extension, and I think we're better off as is (of course > you're free to add your own in your code). > > Of course, such a natural idea is bound to be reused, and one of the > first libraries released by Jérémie Dimino at Jane Street was > precisely such a custom-printf camlp4 extension: > https://github.com/janestreet/custom_printf > > Feel free to reuse it or extend it for any project where it makes > sense. In particular, I don't think that using it implies any > dependency of your preprocessed code on Core, though of course you'll > need Sexplib to use the format-to-sexplib feature. My purely personal > advice would be to seriously explore non-syntax-extension approaches > (combinator library?) before making such a step. I may, unfortunatelly, need some more pointers to understand this suggestion. The problematic code looks somehow like this: (* The following string is much longer than what is inlined here. *) bold_on ^ "mdx" ^ bold_off ^ " " ^ underline_on ^ "command" ^ underline_off ^ " Perform a given " ^ underline_on ^ "command" ^ underline_off ^ ". Section COMMANDS describes all the supported commands." where: bold_on bold_off underline_on underline_off are some strings. It works, but it is ugly. That is why I asked about possibilities to make it more decent. Since Print module is available, I thought that that may be one of the ways how to achieve that. If only I were able to define (non-parametric control strings) that I could use in the following way: "%Bmdx%B %Icommand%I Perform a given %Icommand%I. Section COMMANDS describes all the supported commands." This looks, sort of, OK. I believe that the Print module in batteries 1.4 might enable me to do just that although I need some examples. I do not care too much that given feature disappeared in Batteries 2.0 (Batteries 2.0 is not yet available in Debian stable/testing/unstable and when in descends there, that time might be beyond the lifecycle of the program I am writing. If not, I will bother about it at right time. There might even be more solutions than there are now.). If you mean that it is not technically possible to do what I thought was possible, then I am not against "combinator library", although I am not sure, what do you mean. I would be grateful if you (or somebody) sent a few links to things that might be regarded as combinator libraries and perhaps, if given combinator library existed, that would solve my problem, how it would make my_life_easier & my_code_more_compact than the (somewhat verbose) approach I am currently using (string concatenation).