Camlp5 and OCaml 4.08

Community
1

There is a pull request to port Campl5 to 4.08 OCaml version. But seems like Camlp5 project is abandoned like Camlp4, there is no response for more than a week already, no response for a few months to another PR, and last commit was a half a year ago. To me it looks like project is dead. Maybe it makes sense to move it to the ocaml-community then?

2

Oof, yeah. I made a small PR to add support for raw string literals, and it appears to be in limbo, too. Maybe time to gently ask DDR what he plans to do …

3

I’m going to repeat something that I already said: ocaml-community is neither a graveyard nor a landfill. We do not move there projects that are dead. We moved there projects that are useful/essential, but lack sufficient mainternship.

Personally, I do not believe maintaining camlp5 is in the best interest of the community in any way, but even if it was, we need someone to be ready to step up as maintainer for a while before we move the package, especially for something as big and complicated as camlp5.

Camlp5 has been sort-of-deprecated since before I started using OCaml. As far as I know, the only real users of camlp5 are Coq people. I do not know if that’s still the case, but if it is, I would trust them a bit more to maintain it, since they have a use for it.

7 Likes
4

As far as I know, starting from Coq 8.10 (the next upcoming version), Coq will not depend on camlp5 anymore.

2 Likes
5

Yes, Coq ditched Camlp5 as well. But there are still 4 packages (I excluded Coq-related ones) depending on it:

While every mentioned package has no reverse dependencies, ulex has a lot:

So it makes sense to update Camlp5 for a while, at least until these will not switch to sedlex for example.

1 Like
6

Why is it worse? 5 > 4 but camlp5 is not really the next camlp4. And ~200 opam packages depend on camlp4.

7

Worse because it is not updated for even longer: Commits · camlp4/camlp4 · GitHub

Also from the project README:

Camlp4 was a software system for writing extensible parsers for programming languages. Since 2017, Camlp4 is not actively maintained anymore, and only receives occasional fixes for compatibility with new OCaml versions. Maintainers of Camlp4-using projects are actively encouraged to switch to other systems:

  • For new projects or actively-moving projects, we recommend adopting ppx attributes and extensions, which is now the preferred way to perform AST transformations on OCaml programs.
  • For slow-moving projects or users of other Camlp4 features (extensible grammars), switching to the (maintained) Camlp5 variant of the preprocessor should be easy.
8

Actually, no. camlp5 is the predecessor of camlp4. The numbers are the wrong way around and have nothing to do with versioning.

2 Likes
9

With the proviso that DDR is OK with it, I will happily take over maintaining Camlp5. I use it regularly in projects I write, and would keep it working just for me, if for nobody else.

1 Like
10

I agree with @Drup. I don’t think ocaml-community should adopt camlp5. If people want to take over maintaining deprecated projects for personal reasons in their own domains, that’s fine.

11

It is probably better to move those projects off camlp5 than to maintain it for the sake of a relatively small set of remaining packages.

2 Likes
12

Camlp5 was updated (in master, not yet in opam repository) to support 4.08: camlp5/camlp5@9b9eb12.

13

It’s actually typically rather easy to port Camlp4 and Camlp5 to a new OCaml version. I think that new projects should avoid depending on it, but I don’t see anything deeply wrong for existing project to use it. At every new OCaml release, the same question arises: should one of them do the work of upgrading Camlp4 (or Camlp5) to a new version, or should they migrate to something else, or do nothing?

I don’t see any problem with that, but I’m honestly surprised by how few people have tried to help update their dependencies. Opening issues is nice, but I think it would also be useful to seriously consider sending a pull request to update to a new OCaml version. No one cares very much about Camlp4 and Camlp5 these days, so you may not see how that non-behavior is problematic, but it’s essentially the same with the ppx ecosystem.

14

Daniel (the author of camlp4 and camlp5, and the current maintainer of camlp5) was born and has lived most of his life in a pre-GitHub era. The fact that the project is on GitHub unfortunately does not mean that he is at ease with the way pull requests work. Furthermore, he is less interested in this project now (even if he continues using it for his personal OCaml projects, such as ledit). His current activities have more to do with formalizing math in Coq.

Coq has indeed let go of its camlp5 dependency. The main reason for this is to be able to compile with OCaml trunk continuously. This required to go as far as forking gramlib, a core part of camlp5, but not the one that needs to be patched at each OCaml release. Unfortunately, this also even further condemns camlp5 because Coq developers won’t go anymore to Daniel’s office to ask him to update camlp5.

@Chet_Murthy I think Daniel would be more than happy to give you write-access to the repository and leave you to maintain it, even if he hasn’t answered to you on GitHub. I’ll talk to him about it next week.

2 Likes
15

Since F* (FStar) port from ulex to sedlex just landed it is notable that no alive projects use ulex anymore. The left are all abandoned:

1 Like