ocaml 5.3.0

[giltho]

Hello,
I am trying to compile clangml with ocaml 5.3.0 but I got into a bit of a rabbit hole since:

• I need metaquot to compile with 5.3.0
• I need stdcompat to compile with 5.3.0
• I probably need other libs to compile to 5.3.0

I can see that the 5.2 PR for stdcompat is still open, and was wondering if you are still merging PRs for this work. I'd probably be ok to spend a day or two trying to get all of these upgraded.

Cheers!

[giltho]

Hello!
Happy to this that work is happening 👀
Is this issue resolved now? Would there be any opam release planned if so?

[shindere]

Hello, Many thanks for your interest. The work is on its way but may take a bit of time as it requires the dependencies to be updated, too. But yes, for sure the corresponding Opampackages will be released as soon as possible.

[giltho]

Thank you very much! If there are simple tasks I can help with, feel free to ping here :)

[shindere]

Thank you! To be very clear: I won't hesitate to ask for support but it's also a bit unlikely that I will actually manage to isolate the tasks because I am myself taking over the maintenance of all theprojects under the ocamllibs GitHub organisation. Which means that I mus myself start by understanding all of them, hence the time it takes to get the updates. My hope is that once they will be up-to-date with the most recent versions of the compiler (and of libclang, Python, etc.) things shoudl become more tractable. I am very sorry for the inconvenience thecurrent situation creates for allthe users of these wonderful projects and I can only ensure all of them that I am doing my best to bring things to a better state.

[giltho]

I am not sure what requires an apology here, I am literally just thankful someone is taking this over.

I do have one opinion to offer: I would ditch stdcompat. When I tried upgrading clangml to 5.3.0 myself a while back (before giving up and using Cerberus as a frontend), I found that stdcompat was the main obstacle. What's more, it was also the main obstacle when upgrading pyml to support 5.0+.

I find the added value of stdcompat to be extremely limited. I don't think any project that is actively maintained and would require a new version of clangml needs to be compatible with, let's say, OCaml < 4.08. pyml was using stdcompat to avoid re-implementing two functions (totalling ~10lines of code): In_channel.with_open_bin and String.starts_with. For me, the cost of maintaining stdcompat's and upgrading using à gaz before any update to all projects that depend on it can be made is not worth it.

[shindere]

Hello! A bunch of thanks in return for your interest in these projects and sharing your opinion. I am also super grateful that you mentionned cerberus, which is a project I was not aware of. Regarding whether to keep depending on stdcompat or not, to be honest I have noopinion either way and would rather let @thierry-martinez to jump into this discussion if he so wishes, as stdcompat's author. My understanding of the current situation is that, if stdcompat would have been up-to-date, then depending on it, even for a few functions, would not be a burden and could even be nice to make sure all the projects that need such functions share the same code. To put it another way yes,probably each project that uses stdcompat will likely use only a few of the function it provides, making it seem heavy to have a dependency just for that, but I am underthe impresssion that if you look at the whole ecosystem as a whole, it kindof makes sense to factorize the re-implementaiotn work in one place, namely stdcompat. So theproblem as I understandit is more that stdcompat could not be maintained, rather than its very existence. As Isaid I do absolutely not mind being contradicted on that one. Also, for what it's worth, stdcompat had kindof a significant technicla debt, one reason being that it has two build systems, a dune-based one and one based on GNU autotools. The second one is used by thecoccinelle project, which has not yet been ported to Dune and bundles stdcompat. The dune-based build was invoking configure, which in some cases created subtle issues, in addition to being a bit useless as Dune knows most of thethings configure is so painfully trying to figure out, sometimes wrongly. So a lot of effort has been put in decoupling the two build system, whichmeans that when used within theopam+dune context, the build of stdcompat should be much more robust. Also, release 21.0 ofstdcompat supportingocaml 5.3is on its way, Iwish it will be published by the end of this week, keeping fingers crossed here. I hope this helps to clarify the situation a bit; And, this is just my short term response. In the long run we may makeother decisions.

[giltho]

Thanks for the answer.

I do think there is an issue with stdcompat's existence (at least as it is right now), even if it is is easier to maintain now: it imposes a major bound on the version of OCaml. If I use any dependency which happens to depend on stdcompat (e.g. the version compatible with OCaml 5.3), I cannot upgrade to OCaml 5.4 when it comes out (or better, help with the testing of OCaml 5.4~alpha).

Instead, whenever a new version of OCaml comes out, I must wait for stdcompat to upgrade for compatibility, and then I can upgrade my own version of OCaml. Stdcompat enables retro-compatibility at the cost of future-compatibility. The main issue is that if I decide to use stdcompat, I'm imposing this trade-off to any library or executable that depends on my library, which is not (in my opinon) a reasonable tradeoff.

Though happy to hear from Thierry's opinion.

[shindere]

My understandingof what you write is that it's not so muchthe _existence_ of stdcompat which posesproblems but more how diligently it is maintained and available for newer versions ofthe compiler. It is precisely my purppose to make sure that stdcompat gets released whenever the copiler has a new release. The way I see it, I'd be able to start updating stdcompat as soon as a release branch is forked fromtrunk on ocaml/ocaml, so that Opam packages for stdcompat are available even in the the alpha and beta Opam switches that preceed the official release switch. If I manage that, then I hope things will become less insatisfactory at least at the practical level.