We are happy to announce that a new release of SML.NET is
now available for download from
SML.NET is a compiler for Standard ML which targets the .NET Common
Language Runtime and includes language interoperability extensions for
easy access to .NET libraries.
* 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 local variables. 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 (Beta 1)
release of the Microsoft .NET Framework and Microsoft Visual Studio
.NET 2005. SML.NET remains compatible with the initial 1.0 and 1.1
NB: Although SML.NET fully supports SML polymorphism, SML.NET 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 2.0 (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
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
* 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
* 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
* Windows 98,2000 or XP
* .NET Framework V1.0 or V1.1
* (optional) Microsoft Visual Studio .NET 2002 or 2003
VERSION: SML.NET 1.1 build 1102 of 07-01-05.