From: Dario Teixeira <dario.teixeira@nleyten.com>
To: caml-list@inria.fr
Subject: Re: [Caml-list] META file standards for ppx extensions
Date: Wed, 08 Apr 2015 20:59:22 +0100 [thread overview]
Message-ID: <5297cdaceccd6db2a60700bf686ccfb7@nleyten.com> (raw)
In-Reply-To: <55257AAD.6030004@zoho.com>
Hi,
> I'm not fond of b). ppx_deriving et ppx_import don't follow
> this scheme, and that's rather understandable given the absence
> of runtime library.
Well, if the most popular ppx extensions don't have a runtime
library, this is an argument in favour of the alternative scheme
of declaring the ppx at the top-level of the META file, and the
runtime as a 'lib' or 'runtime' sub-package where applicable.
Personally, I don't think this argument is strong enough to tip
the balance, and I still favour the original scheme I proposed,
but I'm not very adamant about it.
*However*, regardless of what scheme is adopted, can we at least
agree on the need for it to be uniformly applied in the ecosystem?
I think the worst path is the one we're currently following, where
each ppx extension does as it pleases.
> Otherwise yes. lwt, js_of_ocaml follow that and it was widely
> adopted for camlp4, so it shouldn't be an issue.
Well, newcomers to OCaml will not recall this, but we had a similar
discussion some years ago about Camlp4. At the time there was no
'syntax' standard, and most Camlp4 extensions were not even well
integrated with findlib. I think we can all agree that using Camlp4
extensions became much easier and saner after that standard was
adopted by the community.
Best regards,
Dario Teixeira
next prev parent reply other threads:[~2015-04-08 19:59 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-08 18:20 Dario Teixeira
2015-04-08 18:59 ` Drup
2015-04-08 19:59 ` Dario Teixeira [this message]
2015-04-08 20:37 ` Daniel Bünzli
2015-04-09 10:07 ` Dario Teixeira
2015-04-09 10:56 ` Gerd Stolpmann
2015-04-09 12:24 ` Dario Teixeira
2015-04-09 15:33 ` Daniel Bünzli
2015-04-09 16:45 ` Gerd Stolpmann
2015-04-09 17:27 ` Daniel Bünzli
2015-04-09 18:05 ` Daniel Bünzli
2015-04-09 22:26 ` Gerd Stolpmann
2015-04-09 22:21 ` Gerd Stolpmann
2015-04-09 23:06 ` Daniel Bünzli
2015-04-10 8:53 ` François Bobot
2015-04-10 9:42 ` Daniel Bünzli
2015-04-10 10:09 ` Alain Frisch
2015-04-10 11:45 ` Thomas Gazagnaire
2015-04-10 11:04 ` François Bobot
2015-04-10 11:55 ` Daniel Bünzli
2015-04-10 16:33 ` François Bobot
2015-04-10 17:43 ` Daniel Bünzli
2015-04-12 6:00 ` Anil Madhavapeddy
2015-04-10 11:25 ` Gerd Stolpmann
2015-04-10 11:55 ` Daniel Bünzli
2015-04-09 15:45 ` Thomas Gazagnaire
2015-04-09 16:28 ` Dario Teixeira
2015-04-09 16:51 ` Gerd Stolpmann
2015-04-10 12:23 ` Daniel Bünzli
2015-04-10 14:55 ` Gerd Stolpmann
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=5297cdaceccd6db2a60700bf686ccfb7@nleyten.com \
--to=dario.teixeira@nleyten.com \
--cc=caml-list@inria.fr \
/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