new post

Author: bobzhang

website/blog/2018-12-05-release-4-0-8.md

@@ -0,0 +1,46 @@
+---
+title: BuckleScript 4.0.8 (Part One)
+---
+
+Today we made a new release 4.0.8 of `bs-platform`, a detailed list of changes is available [here](https://github.com/BuckleScript/bucklescript/blob/master/Changes.md#408)
+
+Most user visible changes are bug fixes and small enhancement, while quite a few work is done for the upcoming fundamental improvement.
+
+In this article, we are talking about the BuckleScript runtime support and some work we are doing to improve it. 
+
+The design goal of BuckleScript is to make the runtime as small as possible. The runtime of BuckleScript is divided into two parts: the C shims and fundamental language feature support. 
+
+The C shims is not a strict runtime component, in the native backend, the functions are implemented in C stubs, but it does not have to be, either we can implement the C shims in a polyfill style or we can just implement in OCaml and compile it via BuckleScript. We tend to shift more and more such support from runtime to normal stdlib by patching OCaml stdlib with conditional compilation, the benefit is obvious, they are just normal functions which does not need special compiler support, the downside is that we might need do more patches to the libs which use C functions, but considering the more challenging part of maintaining the patches to the compiler, we think such overhead is worthwhile.
+
+If we ignore the C shims, the runtime lib of BuckleScript is very small, and it is pretty easy for experienced BuckleScript programmers to write runtime-free code which generates stand-alone JS code. Such runtime support includes supporting curried calling convention, encoding of OCaml ADT, etc.
+
+The implementation of BuckleScript runtime is that it is written in BuckleScript itself. The benefit is that it is much more maintainable than implementing in JS itself, and it is easier to keep some invaraint when cross the boundary of runtime and stdlib. For example, we don't need worry the consistency of runtime encoding of `type tuple` in BuckleScript, since the runtime is also implemented in BuckleScript itself, and we get three module output for free thanks to such dogfooding.
+
+However, this makes the build system pretty complicated and fragile, the dependency between each module is mostly hard coded and fragile.
+Even worse, this introduced a hard dependency between the normal libs and runtime binary artifacts.
+
+In particular, one [issue](https://github.com/BuckleScript/bucklescript/issues/2772) we want to address is to make the BuckleScript toolchain lightweight. We are still implementing the BuckleScript runtime by using BuckleScript itself, but we want to get rid of dependency in this [issue](https://github.com/BuckleScript/bucklescript/issues/3164). In that case, on the user side, it does not build the runtime lib any more, it is just a bunch of generated JS files, so the complexity of the build system does not impact users at all, this is quite important given that we are committed to support Windows.
+
+In the future, we can just distribute the runtime lib as a noraml js library, and from the BuckleScript's user's point of view it only needs the binary compiler and a small set of JS files, it can use stdlib, belt or whatever they want, it is optional.
+
+To get rid of such dependency between stdlib and runtime, we are going to introduce a breaking change in the future. In hinder sight, our support of catching JS exception exposed the concrete representation of the exception encoding, in particular:
+
+```
+match ... with 
+| OCamlException exn -> ..
+| Js.Exn.Error e -> ...
+```
+In this release, we introduced a funciton to avoid exposing such exception constructor:
+
+```
+match ... with 
+| OCamlException exn -> ...
+| e -> 
+    match Js.asJsExn e with 
+    | Some jserror -> ..
+    | None -> ...
+```
+
+We encourage you to make such changes to make it future-proof.
+
+Oh, the side effect of such refactoring of BuckleScript runtime is that the compilation does not need reading the `.cm*` files generated for its runtime which means faster compilation : )