Investigate removing dependency on result

[hongchangwu]

Is there really good reason to keep this compatibility module now that OCaml 4.03 is 6 (soon 7) versions ago.

The result package doesn't play well with the Result module shipped with 4.08 (see janestreet/result#8). The fact that container uses result means users of container (even transitively) have to use Stdlib.Result to access the Result module from the standard library.

[c-cube]

I imagine we could bump the minimal version to 4.03 and get rid of result and uchar.
Not sure if it's even worth waiting for 3.0.

[pmetzger]

I thought Bucklescript still targeted 4.02.3 for the moment?

[c-cube]

Oh, didn't they release their version targetting 4.06? I'm not following closely…

[pmetzger]

They apparently are supporting both for the moment; BS 7 is apparently in beta and will target only 4.06. I'm not clear on how long it will be until BS 5 is considered deprecated.

[c-cube]

In any case it's a bit of a moot question since they don't want to use containers, but rather Belt/tablecloth/… right?

[ozanmakes]

My 2cents as a user of both Containers and BuckleScript:

• I think I'm one of the few people using these together. I love using Containers as my standard library everywhere, but for BuckleScript I went for a quick & dirty fork. This allowed me to use some Js and Belt functions to (prematurely) reduce some overhead, and drop things that used Format module which affects the final bundle size a lot and not recommended when compiling with BuckleScript.

• BuckleScript versions that target OCaml 4.06 (6.x.x and 7.x.x) seem to be on their way to become the main version. I see fewer and fewer releases of 5.x.x, and flagship tools such as genType dropped support for BS 5.x.x altogether without a period of supporting both.

There are still some work that needs to be done by the community, but all in all I think you should feel free to drop OCaml 4.02 support.

[c-cube]

@osener thanks for the feedback.
I wonder, if there'd be some kind of attribute ([@@no_bs]?) that one could put on definitions, so that BS would just ignore these when compiling? I'm not sure it's possible (the attribute might be lost by the time BS gets the AST, I'm not sure), but it would be neat to be able to support BS users and still keep the Format functions for the rest of us.

[ozanmakes]

Looking at my changes again, I see that I kept a lot of the pretty printing functions without having the same bundle size problems I had with Tablecloth (it's been a while). The rules of BuckleScript's dead code elimination is a bit opaque to me, so I mostly do it by trial and error (maybe it was harder with Tablecloth because it uses a single ml file?).

I also remember that I had trouble getting BuckleScript to compile Containers code that defined non-labelled interfaces over labelled definitions, so I deleted a lot of code and settled on *Labels modules because of my personal preferences.

Regarding [@@no_bs], I'm not aware of such attribute, but it would be fantastic to have Containers support BuckleScript out of the box with a quality JS output that's competitive with Belt. I sense that it was already an inspiration for Belt, so I'm hoping @bobzhang can provide some insight.

[bobzhang]

@c-cube do you use cppo for conditional compilation?

[c-cube]

No, I removed cppo a while ago in favor of dune-driven code generation. It makes development more pleasant since I can use merlin.