In Standard ML the bitwidth of "int" is machine-specific, like in C's "int" and Rust's "isize". Most implementations of Standard ML choose the bitwidth to be o

In Standard ML the bitwidth of "int" is machine-specific, like in C's "int" and Rust's "isize". Most implementations of Standard ML choose the bitwidth to be one bit less than the machine's natural word width, so that the GC mark bit can be stashed in there. For example, 63-bit ints on a 64-bit machine. http://www.itu.dk/~sestoft/mosmllib/Int.html#precision-val http://www.itu.dk/~sestoft/mosmllib/Int.html#precision-val I recall that MLton would stash data in the lower log_2(alignment) bits of pointers for types with alignment requirements (or architectures with memory load alignment requirements), but can't find a reference. There was a paper (ICFP, I think?) about using these bits for reference-counting GC with a fallback to mark+sweep when the count hit the maximum value. Don't think it ever got implemented in a production compiler. I'm pretty sure the "None:Option<T> as null pointer when T is represented as a pointer" optimization happens under the hood in a lot of Haskell+ML compilers. Rust is the first language I've come across that managed to include pretty much all the cool features ML had.