I love SML. After some evenings and nights with Java, I’m really glad to go back to this old but still good language. Some of my work in progress can be find there: TheReturnOfTheSonOfSML. In this post, I just recall some basic rules that I forget after a few weeks of inactivity in this domain.

interpreters and compilers

The easiest implementation is PolyML which have an interpreter and a good compiler. The project is still alive, which is very important.

MLton is a good compiler, which is easy to use but without interpreter. The last version is from February of this year and the previous from 2013. Low activity but not null.

The historic SML/NJ implementation offers an interpreter with a compiler. The latter is not easy to use and I won’t.

There are more but today I will only use these.

a sample program

There is a great hello project which can help us to learn how to structure a source for PolyML and MLTon. If there is a strong standardisation of the language, it’s not the case of the compiling system. It’s why we must do different things for each implementation.

PolyML, first steps

It’ a very permissive system whith one rule: you must provide a main function as the entry point of your program:

fun main() =
	print "Hello, world!\n"

Put that code in a file called hello1.sml and run this:

$ polyc -o hello1.exe hello1.sml
$ ./hello1.exe
Hello, world!

MLTon, first steps

Now, testing with MLTon give a unexpected result:

$ mlton hello1.sml
$ ./hello1

If we create a main.sml like this:

(* main.sml *)

val _ = main ()

and a sort of project file hello1.mlb like that:

$(SML_LIB)/basis/basis.mlb

hello1.sml
main.sml

The test can give us now what we expect:

$ mlton -output hello1.mlt.exe -verbose 1 hello1.mlb
MLton 20180207
MLton starting
   Compile SML starting
      pre codegen starting
      pre codegen finished in 2.28 + 0.71 (24% GC)
      amd64 code gen starting
      amd64 code gen finished in 0.15 + 0.00 (0% GC)
   Compile SML finished in 2.42 + 0.71 (23% GC)
   Compile and Assemble starting
      gcc -c -fPIC -DPIC -I/usr/local/lib/mlton/targets/self/include \
          -std=gnu11 -fno-common -O1 -fomit-frame-pointer \
          -fno-strict-aliasing -w -I/usr/local/lib/mlton/include -m64 -o \
          /tmp/filetXRrV4.o /tmp/filev8cCPy.1.c
      gcc -c -m64 -o /tmp/fileNPOJQ5.o /tmp/filedMrdjS.0.s
   Compile and Assemble finished in 0.14 + 0.00 (0% GC)
   Link starting
      gcc -o hello1.mlt.exe /tmp/filetXRrV4.o /tmp/fileNPOJQ5.o \
          -L/usr/local/lib/mlton/targets/self -lmlton-pic -lgdtoa-pic -lm \
          -lgmp -m64 -Wl,-znoexecstack
   Link finished in 0.03 + 0.00 (0% GC)
MLton finished in 2.64 + 0.72 (21% GC)
$  ./hello1.mlt.exe
Hello, world!

The -verbose option give some indication of the evolution of the compilation. Even if it’s verbose, it’s useful for big project because the compiler is really slower than polyc.