Improve OCaml support

[kwshi]

The current OCaml profile/configuration is largely unusable, for a number of reasons:

• The default "run" button doesn't seem to work at all (prints "Anonymous arg: main.ml", regardless of the contents of main.ml); see https://repl.it/join/iuajzzew-kshi for an example.

• The latest stable release of OCaml is version 4.11.0. The default REPL on repl.it runs OCaml version 4.07, and the OCaml compiler invoked by opening a shell and running ocaml/ocamlc/ocamlopt is the default apt-provided version, currently 4.05. OCaml 4.05 was released about ~3 years ago and is missing several major features/standard-library-modules compared to 4.11, the most notable of which were introduced in 4.08, e.g.:

  • Monadic/applicative binding operators let*, let+, and+, and*, etc.
  • Standard library modules Fun, Bool, Int, Option, Result

• For some background, the industry standard (and hence most well-supported) tool for building OCaml projects is dune. Dune is well-known for its ease of configuration, composability, and advanced editor-support (generating Merlin files) and pre-processor tooling (automatically invoking parser-generators, etc.); a vast majority of OCaml projects are now built using dune. Very few, if any, projects are built with direct calls to the default OCaml compiler ocamlc/ocamlopt, which provide a much lower-level and more cumbersome interface. (Other OCaml build systems, such as OMake and OCamlbuild, have also attempted to solve this problem, but none of them quite succeeded as well as dune did.)

  The repl.it config for OCaml does not provide dune at all, rendering it at best cumbersome and at worst unusable for any sizable project--or even anything much more sophisticated than a simple "hello, world" script.

• The OCaml standard library has been, historically, woefully limited. Though this issue has been largely alleviated by additions to the standard library in recent versions (namely 4.08 and above), several alternative standard libraries, e.g. Jane Street's Base/Core and c-cube's containers libraries still provide many significant conveniences missing from the standard library. A majority of OCaml projects rely on one of these standard library replacements. Their prominence in OCaml projects is analogous, perhaps, to the prominence of Numpy in machine-learning Python projects.

  The repl.it config also currently provides none of these libraries.

---

This PR addresses some of those issues as follows:

• Use a more up-to-date version of OCaml. Since Ubuntu's apt repositories don't provide the latest versions of OCaml, the OCaml toolchain is instead installed and configured using opam.

• Also using [opam], install dune and other common/useful OCaml packages.

Implementation notes:

• opam initializes its files (installation profiles, OCaml libraries, etc.) under ~/.opam by default. Since polygott seems to do some fancy Docker things that mess with the home directory, I pass a --root argument to opam to initialize it under the special polygott-designated home location at /opt/homes/ocaml/.opam.

• Also, opam requires the user to run (or add to their bashrc, etc.) eval $(opam env) to populate the environment with a number of variables such as CAML_LD_LIBRARY_PATH, OCAML_TOPLEVEL_PATH, and PATH to help the OCaml compiler locate where packages/libraries are installed. Their purpose is analogous to the PYTHONPATH environment variable for Python.

  I wasn't sure how best to achieve this with polygott's config options; I tried appending to .bashrc in the setup script (had no effect), and there are no options AFAIK to set environment variables/run shell initialization commands. Instead, what I did was the following:

  • Write the output of opam env --root /opt/homes/ocaml/.opam to /opt/homes/ocaml/.opam_env; when polygott-lang-setup is run, the .opam_env script gets copied to the /home/runner working directory. Then, when the user pulls up a shell, they must run source .opam_env first to get the right environment variables. I find this setup somewhat non-ideal, but I don't know of a better solution.

  • The default compile command is manually prefixed with the right environment variables to help it find its library locations. Again, this is not user-friendly and makes it quite difficult to customize the build command. But I'm not sure what's a better solution; someone more familiar with the polygott infrastructure may be able to help me out here.

• Dune is not invoked by the default compile command (which makes a raw call to ocamlopt). This is because Dune requires the existence of a simple dune configuration file (similar to package.json for Node.js projects, though not exactly in the same way) specifying which modules/executables to compile; without it, Dune is unable to compile anything. Since the entrypoint configuration only allows the creation of a single file, I wasn't sure how to initialize a project structure containing multiple files--an entrypoint together with several dune configuration files. Instead, the only way to use Dune currently is to open a shell, run source .opam_env, then manually call Dune from the shell. Again, doesn't feel ideal--if someone familiar with Polygott best practices has suggestions on what to do, that would be much appreciated! Here are two solutions I can think of, potentially:

  • Construct the default project template/structure within the setup script, under /opt/homes/ocaml.

  • Construct the default project template/structure within the runtimeSetup script, under /opt/homes/ocaml.

  While these two solutions may work, I feel hesitant to take either of those since I imagine *setup scripts are meant for setting up the language and tooling (installing packages, etc.), rather than setting up a project template. But I could be wrong on this, so Polygott experts please advise!

[dan-stowell]

Good afternoon @kwshi ! You've probably noticed by now that we've been slow to merge community PRs on polygott. We've decided to focus on giving Repl.it a stable foundation instead of adding features and updating languages. Once we and our community feel comfortable with Repl.it's overall stability, we'll give this change another look. Thank you for contributing!