Re: [Caml-list] META file standards for ppx extensions

[Dario Teixeira <dario.teixeira@nleyten.com>]

Hi,

> It seems to me that Dario's scheme, that is always have PKG.ppx, is
> more forward looking. We could perfectly imagine that a library in
> the future will implement its functionality using another mechanism
> (for example in a non-ugly way, using a macro system).

Yes, and in the meantime I thought of another reason why the original
scheme (runtime -- if any -- at the META top-level and ppx as a 'ppx'
sub-package) is superior to the alternative (ppx at the top-level
and runtime as 'lib' sub-package): there are libraries where the use
of the syntax/ppx extension is just a nice bonus (LWT, PG'OCaml).
In these cases, the original scheme is the only one that makes sense.

Though there are of course extensions without a runtime where
the alternative scheme would be more sensible, we then run into
the consistency argument: it's preferable to bend one side to the
other than to have a hodgepodge of schemes.  And below you'll find
additional reasons why the original scheme wins decisively.


> We can imagine current packages that are using camlp4 providing
> both a legacy PKG.camlp4 and a PKG.ppx package.

Agreed.  Case in point: LWT.  I don't know when the Ocsigen team
plans to eliminate the LWT Camlp4 syntax extension, but I suspect
that for some time both the Camlp4 and ppx extensions will ship
with LWT.  The former can and should remain accessible via the
lwt.syntax sub-package, whereas the latter is available via
lwt.ppx.

Btw, currently legacy Camlp4 syntax extensions are available as a
PKG.syntax sub-package (not PKG.camlp4), and I see no compelling
reason to change this.


> It also makes it more clear in the build system specification
> what crap pre-processing technology is being pulled in.

Well, apart from the inflammatory use of 'crap', I fully agree!

Best regards,
Dario Teixeira