[Caml-list] syntax extensions with ocamlfind

[Caml-list] syntax extensions with ocamlfind

[Maxence Guesdon]

Hello,

I wrote a simple preprocessor, say mypp in a mykg package, and would
like to make ocamlfind add "-pp mypp" when I call it this way:
  ocamlfind ocamlc -syntax mypp -package mypkg.syntax

(Ideally, -syntax mypp would even be useless)

It seems that ocamlfind only supports camlp4 for preprocessors. Am I
right ? Does anybody known how to achieve this ?

Regards,

Maxence

Re: [Caml-list] syntax extensions with ocamlfind

[Andreas Hauptmann]

On Mon, 2 Mar 2015 18:48:46 +0100
Maxence Guesdon wrote:

> It seems that ocamlfind only supports camlp4 for preprocessors. Am I
> right ? Does anybody known how to achieve this ?

Take a look at the META file of camlp5. If i remember right, it achieves
similar without native support inside ocamlfind.

Re: [Caml-list] syntax extensions with ocamlfind

[Maxence Guesdon]

On Mon, 2 Mar 2015 18:07:40 +0000
Andreas Hauptmann <andreas@ml.ignorelist.com> wrote:

> On Mon, 2 Mar 2015 18:48:46 +0100
> Maxence Guesdon wrote:
> 
> > It seems that ocamlfind only supports camlp4 for preprocessors. Am I
> > right ? Does anybody known how to achieve this ?
> 
> Take a look at the META file of camlp5. If i remember right, it achieves
> similar without native support inside ocamlfind.

Indded, thanks. But it seems that ocamlfind can handle only one
preprocessor, instead of building a command chaining the preprocessors.
When I have more than one packages defining a preprocessor, I get:

  ocamlfind: Several packages are selected that specify preprocessors:
  package camlp4 defines `camlp4', package mypkg.syntax defines
  `./mypp'

And the use of a preprocessor depends on having a "archive" variable
defined like that:
  archive(syntax,preprocessor,dynamow) = "..."

Which must not be empty to make the preprocessor used. If it's empty,
then I get:

  ocamlfind: Using -syntax, but no package is selected specifying a
  preprocessor as required for -syntax

Moreover, ocamlfind automatically adds a -I option to the preprocessor
command, in my case I end up with
  
  -pp "mypp '-I' '/home/guesdon/.opam/4.02.1/lib/mypkg'

So the preprocessor machinery seems very camlp{4,5} oriented.

I think I'll just require the user to add -pp "ocamlfind mypkg/mypp" on
command line option.

Maxence

Re: [Caml-list] syntax extensions with ocamlfind

[Gerd Stolpmann]

[-- Attachment #1: Type: text/plain, Size: 2736 bytes --]

Am Montag, den 02.03.2015, 19:24 +0100 schrieb Maxence Guesdon:
> On Mon, 2 Mar 2015 18:07:40 +0000
> Andreas Hauptmann <andreas@ml.ignorelist.com> wrote:
> 
> > On Mon, 2 Mar 2015 18:48:46 +0100
> > Maxence Guesdon wrote:
> > 
> > > It seems that ocamlfind only supports camlp4 for preprocessors. Am I
> > > right ? Does anybody known how to achieve this ?
> > 
> > Take a look at the META file of camlp5. If i remember right, it achieves
> > similar without native support inside ocamlfind.
> 
> Indded, thanks. But it seems that ocamlfind can handle only one
> preprocessor, instead of building a command chaining the preprocessors.

Chaining isn't that easy. Remember that preprocessors cannot only output
source code, but also parsed ASTs. But ASTs are normally not understood
as input by the next preprocessor in the chain.

Also, preprocessors usually exist to process non-standard syntax. In a
chain pp1|pp2, however, pp1 will most likely not understand the
extensions understood by pp2, and instead run into a parser error. That
makes chaining a questionable concept.

Note that chaining works with the new-style ppx preprocessors. This is
possible because these preprocessors are restricted to the official
syntax (which was extended to make this useful). The ppx chaining is
directly implemented in the compiler.

> When I have more than one packages defining a preprocessor, I get:
> 
>   ocamlfind: Several packages are selected that specify preprocessors:
>   package camlp4 defines `camlp4', package mypkg.syntax defines
>   `./mypp'
> 
[...]
> So the preprocessor machinery seems very camlp{4,5} oriented.

Yes, it is, at least regarding the style the preprocessor is invoked.

What is imaginable is that there is some additional preprocessor driver.
Let's call it ocamlpp. It would do the chaining for those preprocessors
that are compatible. If you call it like

ocamlpp (command | object.cmo) ...

it runs the preprocessors on the command line in turn, either by
executing a command or loading the object. Such a driver would fit into
the findlib framework.

But as said, I doubt that such a driver would be very useful, as
chaining several preprocessors is normally not possible.

> I think I'll just require the user to add -pp "ocamlfind mypkg/mypp" on
> command line option.

I guess so. 

Gerd
-- 
------------------------------------------------------------
Gerd Stolpmann, Darmstadt, Germany    gerd@gerd-stolpmann.de
My OCaml site:          http://www.camlcity.org
Contact details:        http://www.camlcity.org/contact.html
Company homepage:       http://www.gerd-stolpmann.de
------------------------------------------------------------


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [Caml-list] syntax extensions with ocamlfind

[Maxence Guesdon]

On Tue, 03 Mar 2015 10:40:14 +0100
Gerd Stolpmann <info@gerd-stolpmann.de> wrote:

> Am Montag, den 02.03.2015, 19:24 +0100 schrieb Maxence Guesdon:
> > On Mon, 2 Mar 2015 18:07:40 +0000
> > Andreas Hauptmann <andreas@ml.ignorelist.com> wrote:
> > 
> > > On Mon, 2 Mar 2015 18:48:46 +0100
> > > Maxence Guesdon wrote:
> > > 
> > > > It seems that ocamlfind only supports camlp4 for preprocessors. Am I
> > > > right ? Does anybody known how to achieve this ?
> > > 
> > > Take a look at the META file of camlp5. If i remember right, it achieves
> > > similar without native support inside ocamlfind.
> > 
> > Indded, thanks. But it seems that ocamlfind can handle only one
> > preprocessor, instead of building a command chaining the preprocessors.
> 
> Chaining isn't that easy. Remember that preprocessors cannot only output
> source code, but also parsed ASTs. But ASTs are normally not understood
> as input by the next preprocessor in the chain.

This is because "legacy" preprocessors were quite advanced. One
constraint could be that preprocessor read and output text.

> Also, preprocessors usually exist to process non-standard syntax. In a
> chain pp1|pp2, however, pp1 will most likely not understand the
> extensions understood by pp2, and instead run into a parser error. That
> makes chaining a questionable concept.

Indeed, but in my case, my preprocessor is just a lexer, mapping
<:blabla< >> quotes to extension nodes [%blabla ]. So it can read any
other syntax and output it as it is in the original file. I make this
to replace a camlp4 extension. This simple preprocessor maps the
quotations to the ppx world.

> Note that chaining works with the new-style ppx preprocessors. This is
> possible because these preprocessors are restricted to the official
> syntax (which was extended to make this useful). The ppx chaining is
> directly implemented in the compiler.
>

And that's great :)

> > When I have more than one packages defining a preprocessor, I get:
> > 
> >   ocamlfind: Several packages are selected that specify preprocessors:
> >   package camlp4 defines `camlp4', package mypkg.syntax defines
> >   `./mypp'
> > 
> [...]
> > So the preprocessor machinery seems very camlp{4,5} oriented.
> 
> Yes, it is, at least regarding the style the preprocessor is invoked.
> 
> What is imaginable is that there is some additional preprocessor driver.
> Let's call it ocamlpp. It would do the chaining for those preprocessors
> that are compatible. If you call it like
> 
> ocamlpp (command | object.cmo) ...
> 
> it runs the preprocessors on the command line in turn, either by
> executing a command or loading the object. Such a driver would fit into
> the findlib framework.
> 
> But as said, I doubt that such a driver would be very useful, as
> chaining several preprocessors is normally not possible.

I agree this is a corner case. Thanks for your response.

- Maxence