Propose changes to the build system: removing interface only modules support


#1

In OCaml, there is a not well known feature, that a type declaration only module does not need its implementation, however, this is a leaky abstraction, for example:

exception A of int

This module can not be interface only, since exception is not just type declaration, there are other corner cases.

I am proposing to remove interface only module support in bsb, this will not affect most people. For people who are affected, changing mli(or rei) to ml(re) would help.

What do you think? – Thanks


#2

I agree this would be simpler, provided this is documented.


#3

I think this will be a pretty uncontroversial change.


#4

We are going to remove such support in the future. This feature sometimes confused people. For example, when we have a file long_file_name.ml and want to add an interface but had a typo long_fil_name.mli it works silently but in a wrong way


#5

What would be bsb’s new behaviour when it comes across long_fil_name.mli in the future?


#6

It would error out when only mli but no ml file is supplied, note such check is not implemented but something I would like to enforce in the future


#7

Hmm, on second thought, would it be possible to make this a warning (e.g. ‘warning: unused interface file’)? That will give people more flexibility to deal with it. BuckleScript can scaffold project with that as a fatal warning by default.


#8

I think this is fine.

In Dune, for example, you’re asked to explicitly list which modules don’t have an implementation file (e.g. the modules_without_implementation stanza at https://dune.readthedocs.io/en/latest/dune-files.html#executable).

I don’t see a reason to keep this around in BuckleScript other than compatibility with a natively compiled application, but there are may other things where compatibility has been broken or is not possible, so it’s not controversial for me.

This is entering bikeshedding territory, but if it’s not allowed it should just hard error. Not entirely sure what you mean by “scaffolding a project”, but if some other file refers to a module without implementation it would just error later, and I’m generally in favor or producing the errors closest to where the faults occur.


#9

FYI, this will be enforced during next release, thanks for all suggestions!