let binding in OCaml class definition


I like the object layer in OCaml but here’s one quirk of the language that sometimes I forget about and it can bite you…like I just got bit in my OCaml bindings to Java’s ScriptEngine. (Let’s you evaluate JavaScript in OCaml using the JVM)

OCaml lets you define an object like so:

class thing = object
  method speak = print_endline "Hello"

let () = (new thing)#speak

Note that methods don’t need arguments, they will always go off when you call them.

and you can also have fields

class thing = object
  val coder = "coder"
  val mutable name = "Edgar"

  method speak = print_endline (name ^ coder)
  method set_name s = name <- s

let () = 
  let p = new thing in
  p#set_name "Gohar";

Notice that we can also make fields mutable and they are private by default.

Now here’s one situation you might encounter:

class compute = object
  val first_field = Other_module.init ()
  val second_field = Some_module.use_it first_field

This won’t work though because you can’t use one field in another field.

One solution might be:

class compute = 

  let first_field = Other_module.init () in
  let second_field = Some_module.use_it first_field in
    val first = first_field
    val second = second_field

Now question, are first_field and second_field created each time a new instance of compute is made?

The answer is no and this might be counter intuitive to some, at least it was to me and I sometimes forget this.

Verify it with:

class thing =
  let foo = 1 + 2 in
  let () = print_endline "I was called" in


let () =
  let a = new thing in
  let b = new thing in

And see how many times I was called is printed to the screen; hence be aware of this when you use objects in OCaml.

Calling Google Closure programmatically


This is a pretty neat post, I’ll show you how to programmatically call Google Closure in Java. Closure is an amazing project that actually optimizes JavaScript rather than just minifies it. (This is pretty much one of the few times you’ll see me write Java, I think the language sucks).

Its mostly a 2017 update of this post from 2009

Here’s the Java

package com.hyegar.closure;

import java.io.IOException;
import java.util.List;
import java.util.ArrayList;

import com.google.javascript.jscomp.CompilationLevel;
import com.google.javascript.jscomp.Compiler;
import com.google.javascript.jscomp.CompilerOptions;
import com.google.javascript.jscomp.SourceFile;
import com.google.javascript.jscomp.CommandLineRunner;
import com.google.javascript.jscomp.CompilerOptions.LanguageMode;

 * An example of how to call the Closure Compiler programmatically, 
 * this is LICENSED AS GPL-3.0.
 * @author edgar.factorial@gmail.com (Edgar Aroutiounian)

public class CallCompiler {

     * @param code JavaScript source code to compile.
     * @return The compiled version of the code.
    public static String compile(String code) {
	Compiler compiler = new Compiler();

	CompilerOptions options = new CompilerOptions();

	// See :
	// closure-compiler/src/com/google/javascript/jscomp/CompilerOptions.java
	// lines 2864-2896


	List<SourceFile> list = null;

	try {
	    list =
	} catch (IOException e) {
	    System.out.println("Exception raised");

	list.add(SourceFile.fromCode("input.js", code));
	compiler.compile(new ArrayList<SourceFile>(), list, options);
	return compiler.toSource();

    public static void main(String[] args) {
      String compiled_code = compile("var a = 1 + 2; console.log(a)");


You’ll need to have the Closure Compiler installed, on OS X this is easy with brew install closure-compiler

Then in a new directory that you can use for this build, you can copy the jar from /usr/local/Cellar/closure-compiler/20161201/libexec to where the root is of your directory, let’s call that directory build.

Here’s a Makefile which will build, run the code.

	javac -Xlint:deprecation -cp ./closure-compiler-v20161201.jar:./ com/hyegar/closure/CallCompiler.java
	java -cp ./closure-compiler-v20161201.jar:./ com.hyegar.closure.CallCompiler	

variants in C++14 without boost


Variants in their native land

One of the best parts of functional programming are Algebraic Data Types, also known as Sum types, also known as variants. They help you make more type safe programs, self-documenting code.

Here are some examples in OCaml

type 'a option = Some of 'a | None

This is the famous option type of functional programming. A fun thing about option is that its also a Monad, so >>= aka bind is easily defined as:

let ( >>= ) x f = match x with Some h -> f h | _ -> None

Another example recently added to the OCaml standard library is the result type.

type ('success, 'failure) result = Ok of 'success | Error of 'failure

The things prefixed with ' are called type variables, they let you write generic code from the getgo. We only need one for option but we need two different ones for result so that the type of the Ok variant need not be the same as the type of the Error variant.

Once you get an result value, you can pattern match on it:

let process_result = function 
  | Ok r -> (* Do something with r *)
  | Error reason -> (* Do something with the error *)

variants in C++

In C++ variants are not first class citizens of the language, so they need to be provided by a library. In modern C++ our options are C++17’s std::variant, boost::variant or someone’s own rolled version.

I don’t want the boost dependency and I can’t use C++17 so I looked for a library implementation. I found one by mapbox and it fit my usecase perfectly; its a header only template library and I like the API provided. Here’s my implementation of option using the mapbox variant library.

// Let's assume this file is named optional.hpp
#pragma once

#include <mapbox/variant.hpp>

namespace optional {
  struct None { };
  template<typename T>
  struct Some { T payload; };

  template<typename T>
  struct Optional : mapbox::util::variant<None, Some<T>> {
    using Base = mapbox::util::variant<None, Some<T>>;
    using Base::Base;

  // These two are helper functions, like std::make_unique, etc.
  template<typename T>
  auto some(T x)  { return Optional<T>{Some<T>{x}}; }

  template<typename T>
  auto none(void) { return Optional<T>{None{}}; }


And here’s an example usage:

// Let's assume this file is named main.cpp
#include <string>
#include <iostream>

#include "optional.hpp"

// This lets just make std::string just by adding a suffix of 's'
// to things that otherwise look like char *
using namespace std::literals::string_literals;

// Pretend that this is something that could fail.
auto file_contents(void) {
  return optional::some("some file contents"s);

int main(void)
  	   [](optional::None) {
  	     std::cout << "Check if file existed\n";
  	   [](auto some) {
  	     std::cout << "File contents: " << some.payload;

and you can easily compile it with, assuming that you added mapbox/variant.hpp to your compiler’s include search path…

$ clang++ -std=c++14 main.cpp

Happy coding.

node's async, await, Promises.


While studying for interviews I’m talking breaks by working on silicondzor.com

This is giving me some real web dev experience and I’m using the latest and greatest features of JavaScript and node.

One thing that I’m really liking in modern JavaScript is the async story, it reminds me a lot of OCaml and both are somewhat converging, i.e ES6’s introduction of Promises which are basically 'a Lwt.t, and Lwt renaming Lwt.t into Promises in 2.7.0.

Here’s like my conceptual cheatsheet about using Promises from scratch, converting an callback API into a Promises API and then taking it to the next step with async, await.

Basic callback APIs

node uses an event based programming paradigm and this is reflected in basically all server side code, ie the trailing callback argument to asynchronously call once the task completes.

Let’s simulate it with this function

// Plain CB based API
const test_func = (item, cb) => {
  setTimeout(() => {
    if (item < 5) cb(null, 'Success');
    else cb(new Error('Oops'), null);
  }, 3000);

test_func(3, (err, success) => console.log(success));

This models typical node code, the callback being called three seconds after execution of test_func

This seems pretty fine for this example but once you have logic that is dependent on the success of one callback API after another then you start to have a difficult to reason about triangle of callbacks on the screen.


ES6 introduces Promises and these are quite convienent, think of a Promise as being a box which will have a value in it sometime later.

We can turn any callback based API into a Promises based one.

// Promises based
const test_func_promise = item => {
  return new Promise((accept, reject) => {
    test_func(item, (err, success) => {
      if (err) reject(err);
      else accept(success);

.then(item => { console.log('Sucess!!', item); })
.catch(err => console.error(err));

When you create a new Promise you need to provide it with two function, one to be called when there’s a success and when the Promise should fail. Hence when calling test_func_promise returns a Promise, not the value 'Success'. Also if you use the plain Promises approach be sure to include a .catch call.

This is nicer than the original callback API approach, but now all your success or failure logic and everything following that effectively has to be all in either .then or .catch and that’s a bit awkward still.


ES7 introduced async, await where I basically think of the latter as >>= and async as sort of like >|=. With async, await we can call Promises based code as if it was synchronous code.

const test_func_async_example = async (item) => {
  try {
    const result = await test_func_promise(item);
    console.log(`Yay: ${result}`);
  } catch(e) {
    console.error(`Messed up: ${e}`);


First notice how whatever function we use await inside of, we need to tag that function with async and now this function returns a Promise

Now when we call test_func_promises with await prefixed, then we get the value that the Promise resolved. Also whatever the reject condition of the Promise was then becomes the exception of the catch following the await usage.


async, await are very powerful features of ES7, Promises are from ES6. Not every JavaScript engine supports ES7 so you’ll have to use babel to compile your async, await to runnable code; basically turns the async, await to generators (also an amazing topic).

On newer versions of node, I’m using v7.3.0, you can turn on features from the future with command line arguments. Check all of them with:

$ node --v8-options | less

I’m turning on native async, await with --harmony_async_await, so my final invocation is:

$ node --harmony_async_await test.js

You can get all the code as one script here

Using JavaScriptCore with examples



I like mixing languages and I especially like OCaml, JavaScript. Lately I’ve been writing OCaml bindings to JavaScriptCore, JSC is what underpins Safari both iOS and desktop variants, and ReactNative. When you’re writing bindings, you kinda need to know the C/C++ library that you’re binding to.


We’re going to provide a pretty meaty example, we’ll make a custom object in C++ code, then we’ll use it from a JavaScript script. Imagine we want to expose a File like object, JS the language itself has no notion of a File, so it will need support from the C/C++ level; you can imagine this as the objects that say [native code].

Here’s the code, afterwards is a detailed breakdown (The R C++ feature confuses the syntax highlighter)

#include <string>
#include <iostream>
#include <JavaScriptCore/JavaScriptCore.h>

std::string getcwd_string(void)
   char buff[PATH_MAX];
   getcwd(buff, PATH_MAX);
   std::string cwd(buff);
   return cwd;

const char*
jsvalue_to_utf8_string(JSGlobalContextRef ctx, JSValueRef v)
  JSStringRef valueAsString = JSValueToStringCopy(ctx, v, NULL);
  size_t jsSize = JSStringGetMaximumUTF8CStringSize(valueAsString);
  char* jsBuffer = (char*)malloc(jsSize);
  JSStringGetUTF8CString(valueAsString, jsBuffer, jsSize);
  return jsBuffer;

void run_example(void)
  JSClassDefinition definition = kJSClassDefinitionEmpty;
  definition.className = "File";
  definition.callAsConstructor = [](auto ctx,
				    auto object,
				    auto argumentCount,
				    auto arguments[],
				    auto *exception) -> JSObjectRef {
    auto file_name =
    JSValueMakeString(ctx, JSStringCreateWithUTF8CString(getcwd_string().c_str()));
    auto prop_name = JSStringCreateWithUTF8CString("cwdName");
    auto example_obj = JSObjectMake(ctx, nullptr, nullptr);

    return example_obj;

  auto ctx = JSGlobalContextCreate(nullptr);
  auto js_example_class = JSClassCreate(&definition);
  auto example_obj = JSObjectMake(ctx, js_example_class, nullptr);
  // auto called_result = JSObjectCallAsConstructor(ctx, example_obj, 0, nullptr, nullptr);
  // auto property_check =
  //   JSObjectGetProperty(ctx,
  // 			called_result,
  // 			JSStringCreateWithUTF8CString("cwdName"),
  // 			nullptr);

  // std::cout << jsvalue_to_utf8_string(ctx, property_check) << std::endl;
  std::string code_to_eval = R"(
const example_code = new File;
  JSValueRef exn;

  auto global_object = JSContextGetGlobalObject(ctx);

  auto sanity_check =
  if (exn)
    std::cout << jsvalue_to_utf8_string(ctx, exn) << std::endl;

  std::cout << jsvalue_to_utf8_string(ctx, sanity_check) << std::endl;

int main(int argc, char **argv)
  return 0;

compile with, should work just fine on Linux as well, but using:

libjavascriptcoregtk-4.0 instead of the -framework JavaScriptCore

$ clang++ -framework JavaScriptCore -std=c++14 jsc_examples.cpp -oF 


The real meat of the code starts at run_example. We start by creating a JSClassDefinition, this creates a template that lets us control all the behavior of our custom object. Then we provide an implementation for what code ought to be run when our custom object will created with new, notice using C++14’s nice ability to use auto for the parameter names, also notice that we explicitly have to give back the return type of JSObjectRef, you get a bit spoiled by the OCaml type system. Then we create a JavaScript object, set the property cwdName and return that new object from the constructor call.

Then we need to make a global context, this is like the environment that your JavaScript runs in and we grab the global object out of it, like window in the browser. (The commented out code is if you wanted to call the constructor and get the result directly in code)

We set the class object as a property to the global, aka like doing window.d3 = //d3's code. Then we evaluate a script, some fun trival all your <script> tags actually have a return value, its the last value.


FWIW I’m doing the OCaml bindings here github stars appreciated :)