What is holding you back from upgrading to the latest OCaml compiler?

Does merlin have support for this future syntax system? If not, I feel it is not really helping.

I had issues with merlin and ocamlformat along these lines, and so actively developing code with future_syntax was difficult.

Is there a solution?

1 Like

Just here to chime in that future_syntax can’t be combined with other preprocessors, which made it a no-go for us, unfortunately.

2 Likes

future_syntax is targetted at people who develop using a recent compiler but want to make their software available to people using an older compiler. If you develop using an older compiler, then you are effectively not going to get a very good experience. Thinking about it, maybe the name is not so clear and should be something like syntax_shims instead :thinking:

Releasing support for let+ before 4.08 was even released was a bit premature and effectively the whole ecosystem is not yet ready for it. However, we were really eager to have a let-syntax in dune because we use a lot of applicatives and monads. And we can’t use ppx in dune. So overall we were ready to give up merlin for a little while.

Once 4.08 has settled in and 4.08 is what most people use for their day-to-day development, future_syntax will no longer get in the way since it will be a no-op.

You are right that the lack of integration with ppxlib is a deal breaker if you use ppxlib. I have plans to develop future_syntax and integrate it with ppxlib. However, it is a non-trivial amount of work and we already have a packed todo-list, so it will take a bit of time.

2 Likes

Just to make things clear the only thing that this package provides for now is the Stdlib module to handle the deprecation of Pervasives.

After a discussion with @jeremiedimino we decided not to provide new modules (e.g. those introduced in 4.08) for now in order to entice the eco-system to move on to later versions of the compiler.

1 Like

Note there is also a distribution problem - at least half of the Linux/BSD distributions stick to the old OCaml versions: https://repology.org/project/ocaml/versions

1 Like

For the record, I’m trying to update from 4.05 to 4.07.1 and our build (see Test / Production module injection) fails to build in 4.06 already. I’m working it but this pattern prevents us to upgrade at the moment

1 Like

@vsiles, once you have completed the update, it would be great if you could drop a few words here about the problem you encountered :slight_smile:

In my experience the biggest issues with upgrading versions have been ppx_deriving (or its other plugins) not being up-to-date for the newest OCaml release (and even when master has a fix there is no release for a long time as happened with this commit).

So usually we are either on the current version or are one version behind. We don’t tend to use beta versions of the compiler since that basically guarantees that there will be some dependency that will prevent us from compiling.

1 Like

I’m not held back. Orsetto dropped its dependencies on everything that isn’t yet ready for OCaml 4.08, and I’m adopting a new rule that PPX rewriting will never be required with whatever is the latest release of the compiler.

This time another big obstacle to upgrades is the many new deprecations that prevent code that uses Pervasives (or Yojson.t in a similar vein in the ecosystem) that kills normal dune projects in dev. So in my experience so far, I have to do some work for my librairies to compile cleany in dev mode on both 4.08 and older versions (using dune to generate shims, etc.).

So I’m almost done upgrading. The main blocking “issues” are:

  • the fact that --keep-locs is now the default and we do shady stuff :smiley:
  • we now depend on ppx_tools_versioned 5.2.1 but flowtype requires 5.2 exactly, so we have to wait for some deps to be updated.

Some feedback about non blocking issues:

  • add new -unsafe-string for some files
  • minor change in the API (mostly core related, not ocaml) with missing ~f: or ~f: changed to `~compare:~
1 Like

The lab machines we use for teaching are based on Debian stable which means that the default OCaml compiler is currently 4.02.3 (soon to become 4.05.0, if I understand correctly). Installing opam to use a more recent version requires (1) an additional technical step and risk of confusion for beginners who sometimes already express a preference for a more familiar programming language and (2) a certain amount of disk space in student home directories mounted from a network share.

Maybe this does not matter. For such introductory courses, there is probably little need to use the latest compiler and related packages. Do other people have similar issues when using OCaml for teaching?

1 Like

Unrelated to OCaml, but during teaching reverse engineering with radare2, Debian-based distributions are always a big pain, since always there is a someone who uses ancient version from the packages. Of course you can’t compare radare2 and OCaml infrastructure due to the sheer size difference. But at the same time, ignoring huge advancements in the language itself, tools and libraries will shy students away even further.

Yes, I agree. Also, I made a small mistake, our lab machines run the latest version of Ubuntu, but the system install of OCaml is still 4.02.3.

Since this is for teaching, couldn’t you get at least a backport of 4.05.0 installed?

Yes, I could probably convince the admins to make that change. It’s not an insurmountable problem. I just wanted to add this consideration to the list and I wondered what other people thought. (I also know that maintaining many versions of software is time-consuming, thankless, and error prone!)

We’re switching to teaching in OCaml for our first year Foundations of Computer Science course in Cambridge, and I am putting together an OCaml/Jupyter Hub environment for our students. This setup means that there is no client-side software required by the students to start with, and then they can subsequently (after a few weeks of the basics) get a local environment running if the notebook environment isn’t powerful enough. Mostly though, we avoid any dependency on package management for student teaching and provide an explicit repository with all the build/exercise instructions.

I’ll share details of our Jupyter setup in a separate thread in a month or so once the quirks are ironed out. @jonludlam and I would like to get it to be a jsoo-based purely-client-side experience, but that may be out of scope for this year’s teaching. This used to with with iocamljs, but the Jupyter codebase has diverged quite a bit since @evilkidder wrote iocamljs sadly!

3 Likes

@avsm Have you considered using learn-ocaml? The Paris 7 OCaml course switched to it this year (I was TAing), and AFAICT it provides most of the jsoo-based purely-client-side experience you mentioned.

Additionally, having more teaching material written for the platform would be really nice for teaching OCaml even outside of this course.

Considering it in the future, but not for the next academic year. We’re also hoping to use Jupyter for a scientific computing course in Python, so there are some external reasons such as integration with local systems that make it hard to move quickly. The Learn OCaml team kindly switched the license from AGPL to MIT earlier this year which brought it back into the running as a possible option for us which is hugely appreciated.

(To get this thread back on-topic to the original post) – it is most useful to have these style of hosted notebooks/client-side compiler platforms for teaching since we can centrally manage the version of the compiler being deployed and upgrade it fairly invisibly behind the scenes.

Main reasons I stay on older OCaml versions have been due compiler forks [MetaOCaml and Multicore OCaml for example]

For software that has to be widely distributed such as Coq we follow https://repology.org/project/ocaml/versions and usually require the minimum that makes it packageable for Debian / Ubuntu.

1 Like