From: Matej Kosik <5764c029b688c1c0d24a2e97cd764f@gmail.com>
To: Gabriel Scherer <gabriel.scherer@gmail.com>
Cc: "caml-list@inria.fr" <caml-list@inria.fr>
Subject: Re: [Caml-list] [batteries] ... how to create (format) directives that do not take any arguments?
Date: Wed, 27 Nov 2013 11:37:20 +0000 [thread overview]
Message-ID: <5295D970.8090601@gmail.com> (raw)
In-Reply-To: <CAPFanBGc_1gKtuzBGJCfuJzf8D=HbiOHW7y-mQpFjoPtNSJ4uQ@mail.gmail.com>
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).
next prev parent reply other threads:[~2013-11-27 11:37 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-25 15:46 Matej Kosik
2013-11-25 16:27 ` Gabriel Scherer
2013-11-27 11:37 ` Matej Kosik [this message]
2013-11-28 6:30 ` [Caml-list] [batteries] ... how to create (format) directives oleg
2013-11-29 9:32 ` Matej Kosik
2013-11-30 3:15 ` oleg
2013-11-27 11:54 ` [Caml-list] [batteries] ... how to create (format) directives that do not take any arguments? Jeremie Dimino
2013-11-27 12:52 ` Matej Kosik
2013-11-27 13:00 ` Jeremie Dimino
2013-11-29 9:32 ` Matej Kosik
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5295D970.8090601@gmail.com \
--to=5764c029b688c1c0d24a2e97cd764f@gmail.com \
--cc=caml-list@inria.fr \
--cc=gabriel.scherer@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox