bucklescript.github.io | BuckleScript 's documentation site

Looks like they screwed up the precedence of -> so that it's actually interpreted as

I actually don't think this is a very good use case for %raw, but would rather just use an ordinary external:

You can prefix the fields with an underscore, which will be removed in the generated JS:

BuckleScript can output modules in a number of different module formats, which can then be bundled up along with their dependencies using a bundler such as webpack or rollup. The output is not really intended to be used as a stand-alone unit, since you'd be rather limited in what you could do in any case, as the standard and runtime libraries are separate modules. And even something as trivial as multiplication will involve the runtime library.

You can configure BuckleScript to output es6 modules, which can be run directly in the browser as long as your browser supports it. But that would still require manually extracting the standard and runtime libraries from your bs-platform installation.

The module format is configured through the package-specs property in bsconfig.json:

It's called an abstract type, and is usually used to hide the structure of the underlying data, but is particularly useful with BuckleScript because the underlying JavaScript structure isn't necessarily even representable as a native OCaml type.

It's not polymorphic, however, just an opaque type.

The nature of FFI might complicate the concept a bit, though. Foreign "functions" are by definition untyped, and the process of defining an FFI using externals is one where you tell the compiler what the types of these functions are. So you could tell the compiler that toString returns an int if you want, and it won't know the difference until you actually try to use it as an int, which will of course end badly.

But since abstract types are user-defined and don't have structure you'll have to define all the functions that can operate on it yourself, via the FFI. You can't manipulate it in OCaml (unless you circumvent the type system at least), so it's just a black box that enables you to carry a value from one FFI function to another.

It should be in the "package-specs" section:

Yes, attribute precedence and such is unfortunately subtly different. Reason Tools (which is great for converting small snippets like this) says this is what you want: