As much of a gem as Poly/ML might be, I just use MLton* exclusively, because its .mlb aka MLBasis build-system seems by far the most sane way to actually make use of multiple source files when writing SML code.
*another gem
*another gem
These scripts are really limited. They only support the simplest .mlb files that are really just lists of other files, and the semantics are technically incorrect because they have no way to reset the environment when beginning each new .mlb file in, as the spec says they should. I use them scrappily during development and then generally use MLton for production builds. But you can get quite a lot done within those limitations, and it's very nice to have the faster compilation of Poly/ML, as well as the option of seeing error messages from more than one compiler.
That you can use CM as a library has always been really handy, but otherwise the same, using MLton for production builds.
MLton can do it's whole program optimization then output to LLVM which I believe should then be able to do auto-vectorization.
I don't have measurements to hand, but vaguely speaking, low. Low enough to be worth using for even quite modest calls into vector functions or optimised libraries.
> And can you pass SML function pointers into C code as callbacks?
Yes. At least, you can declare a function statically for export as a callback. You can't pass arbitrary function values.
You can call C/C++ from SML, and call SML from C/C++ from SML - though some neat potential uses are ruled out as MLton (unlike Poly/ML) doesn't support native threads and you can't call back from a different thread from the caller.
You can also compile to a library using MLton and use that from a C/C++ program - again only from a single thread, but it doesn't have to be the program's main thread.