Make a trade off between module alias and linking behavior

[mlms13]

Minimal demo repo: https://github.com/mlms13/bsb-520-include

Per this comment in #3839, I've been trying to clean up impure modules to avoid the unnecessary explosion of imports in the compiled JS. I noticed that the following OCaml:

include SemiringExtras.Make(IntSemiring)

let v = increment 3

Produces the following JS:

var include = SemiringExtras.Make(IntSemiring);

var increment = include.increment;

var v = Curry._1(increment, 3);

...

/* include Not a pure module */

You can see more context in the sample repo, but in this case IntSemiring is pure and SemiringExtras is pure, so I'm not sure what's causing the include to make the module impure. At first I thought this was a regression with 5.2.0, but I've been able to reproduce it with 5.0.4 as well.

[anmonteiro]

SemiringExtras doesn't look pure.

let increment = S.add S.one

When applied S.one to produce the result, S.add could perform a side effect, causing it not to be pure.

[mlms13]

OK, how do I convince Bucklescript that it is in fact pure? Because the net effect is that this "impurity" is adding dozens of unused imports to my bundled JS...

S.add could perform a side effect

I guess maybe I'm not understanding how purity is checked. By this reasoning, how is any function application known to be pure at compile time?

[anmonteiro]

let add first = 
  Js.log "Foo";
  fun second ->
    first + second + 1
;;

^ This is the concrete example of what I'm talking about -- the signature is still val add: int -> int -> int, but add 1 is not pure, nor is add 1 2.

I don't know what kinds of purity checks BuckleScript has, so I can't speak to that.

[mlms13]

I don't know much about the internals, but shouldn't that be caught where add is defined? It's true that SemiringExtras doesn't know if the module passed to it is pure, but it only does pure things with that module, so it seems strange to assume that the whole tree of modules is impure at that point.

[bobzhang]

Hi @mlms13 our purity analysis is primitive. Essentially function application (except few cases which is inlined) is classified as impure. Here functor application is exactly the same as function application underlying. Functor application is a runtime behavior not compile time thing.

There is another use case which can delay functor application, would you have a look at how Belt.Map is implemented

In the short term, there is no plan to refine the purity analysis, so I am going to close this issue

[mlms13]

I understand the reasoning for closing both this and #3839, but in practice, the combination of the two issues means that every project that uses Relude (or any project that depends on relude, such as bs-decode) ends up importing every single module in a rather large standard library in the bundled JS.

It would be nice if there was something Bucklescript could do to help us out here, since this wasn't an issue prior to 5.2.0.

[andywhite37]

@bobzhang - can we have a little more discussion about this? If modules are being more aggressively assumped to be impure, and this results in more things being auto-imported into the .js files, it's going to wreak havoc with download sizes. What changed between 5.0.4 and 5.2.0 (or whenever this changed) that caused this behavior to start?

[mlms13]

In this case, I think the main change in 5.2.0 was #3839. The "impure" modules already existed (I checked as far back as 5.0.4), but their impurity didn't really matter.

I tested bundling es6 modules using Rollup (which is supposed to be good at tree-shaking as far as I know), and the one-line example repo (Js.log (Relude.List.toArray [])) has an extra 50kb with 5.2.0 compared with 5.0.6.

[bobzhang]

@andywhite37 I believe it is that we removed -no-alias-deps by default, which caused a subtle build system bug.
I think it is okay to have a file with purely module alias to use the old behavior

(* all are module aliases *)
module A = X_A
module B = X_B 

But I am unsure it is sufficient to restore the old bundle size

[bobzhang]

I can add a dirty patch to see if it is what you want

[mlms13]

I'm not 100% sure, but I'd guess that special-casing modules that only have module aliases in them would fix the increased bundle size we're seeing with Relude.