Visual Studio Support
Mailing list

Theory and Semantics Group
Computer Laboratory
University of Cambridge

Pages maintained by
Nik Sultana
Last updated 02-June-06


Functional programming on the .NET CLR

SML.NET is a compiler for the functional programming language Standard ML that targets the .NET Common Language Runtime and which supports language interoperability features for easy access to .NET libraries.

This web site was last updated on 02-June-06.


SML.NET is available for download in either binary or source form.

The current version is: SML.NET 1.2 build 1613 of 02-June-06.

New in This Release

Major improvements to the Visual Studio Integration Package
Much more accurate and reliable Intellisense; hovering over a keyword reports the type of its smallest enclosing expression; hovering over a pattern reports the types of its bindings.
Major improvements to Debugger Support
Bindings in the Locals window now enter and exit scope appropriately. The values of sub-expressions, not just identifiers, are reported as locals in Locals window. Most constructed values now have symbolic tags derived from the constructor name. Values of heap-allocated SML datatypes now support ToString() and ToString(int depth) methods that can be invoked in the VS Immediate window to inspect values at runtime. Improved stepping behaviour. SML.NET stack frames now typically have meaningful, not mangled, source names.
Preliminary support for Whidbey
The distribution has been updated to support the current 2.0 release of the Microsoft .NET Framework and Microsoft Visual Studio .NET 2005. SML.NET remains compatible with the initial 1.0 and 1.1 releases.

NB: Although SML.NET fully supports SML polymorphism, it does not yet produce or consume .NET generics (we hope to in future): this release just allows you to continue working with your existing SML.NET code on the Whidbey platform.

Improved code generation and performance
SML.NET now makes much better use of locals and the stack; pattern matching is compiled as a switch when appropriate.
Various bug fixes
Including: the annoying (but benign) overflow error when persisting compilation units has been fixed; SML.NET now exploits some previously missed opportunities for tail-recursion.


Support for all of Standard ML
SML.NET compiles all of SML '97 (with some very minor discrepancies).
Support for the Basis library
Almost all of the Standard ML Basis Library is implemented.
Seamless interoperability with other languages
SML.NET extends the SML language to support safe, convenient use of the .NET Framework libraries and code written in other languages for the CLR, such as C# or VB. SML.NET can both consume and produce .NET classes, interfaces, delegates etc.
Command-line compilation
SML.NET supports traditional compilation from the command-line.
Interactive compilation environment
Alternatively, you can control the compiler from an interactive environment. This lets you set and query options incrementally and to see the signatures of compiled and imported SML.NET modules.
Automatic dependency analysis
In either mode of compilation, the compiler requires only the names of root modules and a place to look for source code. It then does dependency analysis to determine which files are required and which need recompilation.
Produces verifiable CLR IL
The output of the compiler is verifiable MSIL (Microsoft Intermediate Language) for the CLR.
Whole program optimization
SML.NET performs optimizations on a whole program (or library) at once. It usually produces small executables with fairly good performance.
Integration with Visual Studio .NET
A binary distribution includes an experimental package for Microsoft Visual Studio .NET 2002, 2003 and & 2005 that allows you to edit, build and debug SML.NET projects from within the development environment.


No interactive evaluation
The interactive environment is for compilation of stand-alone applications or libraries only. SML expressions can not be evaluated interactively and the use command is not available. For programs that make no use of the language extensions it is possible to develop and test them using a compiler such as Moscow ML or Standard ML of New Jersey and then to use SML.NET to produce final executables.
Whole program optimization
Top-level SML modules are not compiled individually to .NET object code. Instead, some compilation takes place on separate modules (type checking, translation to the compiler's own intermediate form, and some optimizations) but most is deferred until after the linking together of top-level modules. This improves performance of the generated code, but significantly increases (re)compilation times.
Only CLR types at boundaries of compiled code
The exposed interfaces of applications or DLLs compiled by SML.NET may only refer to CLR types (classes, interfaces, delegates, etc.). They may not expose SML-specific types (functions, datatypes, records, etc.). In particular, this restriction means that one cannot compile an arbitrary SML module into a DLL for consumption even by other SML.NET programs: the module must be either linked into the client program at compile-time or use only CLR types at its interface.