Possible decoupling

[SMHC36776]

Hi,

I'm new to the codebase of MLton, but upon a fairly superficial review of the repository, I was pondering whether it would be beneficial to separate the runtime and basis library into their own repositories. Have there been any past attempts to refactor the codebase, or any plans to do so in the future?

[MatthewFluet]

Certainly no immediate plans.

The compiler proper, the runtime system, and the basis library implementation all make a lot of assumptions about the others, so it isn't clear that one could separate them and still maintain consistency between them. Similarly, various features (or, at least aspects of features) have, over time, migrated between the different components.

It is the case that some platforms (e.g., Debian/Ubuntu) choose to package them as different components; at least in the case of Debian/Ubuntu, one reason is that the Basis Library source code is architecture independent, so can be shared between all of the different architectures.

Could you say what benefits would come with decoupling?

[SMHC36776]

I presume that the benefits could simply be summed up as reducing redundant components and unnecessary steps during the build and installation phase. It isn't a critical error in the implementation of the compiler or the libraries that are distributed with it. I suppose some of my opinions may be nitpicky though.

For example, if the MLton codebase is being built with a pre-installed version of MLton, then it may be redundant to rebuild the runtime system for the new version of the compiler which most likely targets the exact same version of the runtime as the pre-installed compiler. It may seem more practical to share one precompiled runtime between both of the compilers, although it may be possible to specify a precompiled compatible runtime system as a parameter during the build phase. I think it's fairly unlikely that modifications to the MLton codebase will require modifications to the runtime system.

Also, the basis library that is distributed with the MLton codebase is not necessarily a dependency for the MLton codebase that is being built, but rather, it is a dependency for any ML codebase that is being built with the new version of the compiler. Although, it is not exactly clear to me whether it depends on the version of the basis library that is distributed with the MLton codebase, or whether it simply depends on the basis library that is pre-installed with the existing compiler. The basis library that is installed with the new version of the MLton compiler will most likely be almost identical to the basis library of the pre-installed compiler, and the pre-installed basis library will most likely be compatible with the new version of the compiler as well.

It wouldn't be possible to release a new version of the basis library (if the definition is updated) without releasing a new version of the compiler itself, even when the implementation of the basis library doesn't require new language features. It effectively delays any updates or potential corrections to the basis library, rendering certain releases permanently defective (without extraneous post-installed corrections to the basis library), even when the implementation of the compiler itself is perfectly functional in compliance with the definition. And given that the MLton extension modules are coupled with the basis library, any changes or potential corrections in the extension modules would presumably require a new release of the basis library that is distributed with the codebase. It may be more practical to distribute certain extension modules with the runtime system rather than the general basis library.

[MatthewFluet]

Not sure that there is anything immediately actionable here. Closing, but feel free to open a new issue or pull request for something more specific and actionable.