The feature looks fine but I'm wondering if this should be an env option. It seems like something you'd only want to enable for subsets of your project where alternative extensions are allowed.

The feature looks fine but I'm wondering if this should be an env option. It seems like something you'd only want to enable for subsets of your project where alternative extensions are allowed.

A per-project granularity is enough for my use-case; but if you think the extra generality is worth it, I can try to make it into an env option. I did not do this because the plumbing looked more complicated...

Okay, then let's not bother. However, the fact that the plumbing for for Env_node is a bit more complicated is a a general problem that needs to be solved. It should really be the same amount of difficulty.

For symmetry I would also like to support Reason; I thought of the following syntax, which would express the default setting of dune:

(module_extensions
  (impl (ocaml ml) (reason re))
  (intf (ocaml mli) (reason rei)))

What do you think?

Also, do we want intf (resp impl) or interface (resp implementation) ?

I have been wondering about providing first class support for defining derived languages such as reason. For instance, reason support could be defined as follow (though we'd keep it a builtin):

(define_derived_language
 (name reason)
 (file
  (kind impl)
  (extension re)
  (convert (run refmt --print binary %{input-file}))
  (format (run refmt %{input-file})))
 (file
  (kind intf)
  (extension rei)
  (convert (run refmt --print binary %{input-file}))
  (format (run refmt %{input-file}))))

convert would be used for producing a file to feed to the compiler and format would be the code formatter to use instead of ocamlformat.

That would cover this PR as well as anyone who would want to implement their own dialect of OCaml.

This will be fixed in a more general way by #2404