§ 1.6. Limitations in SML# version 1.0.1

We have successfully developed all the features listed in Section 1.1, which we had initially aimed at. The version 1.0.1 contains most of them, with the following restrictions.

1. Optimization.

   In this version, optimization is far from adequate; it does not even implement standard ones such as inlining and constant propagation. So both the compilation time and the speed of generated code are not very satisfactory. We have started design and development of optimizing SML# compiler, and hope that we will provide an optimized SML# compiler that is as fast as other mature compilers.

2. Interface language.

   To support separate compilation, we have defined the interface language for SML# source code. This is our initial design and has a room of improvement. We hope to improve the interface language based on our experience and other user's comments and requests.

3. Native thread support on malticore CPU.

   This feature has not yet been well tested. So we set it off by default. To enable it, give --enable-thread to ./configure. The compiler then generate thread-safe code. If you import OS thread-library through _import declaration, your multithread code should run on multicore CPU.

   We have also completed development of a fully concurrent non-moving GC. This has not been integrated in 1.0.1 version. The GC in the 1.0.1 version is a stop-the-world multithread extension of the non-moving GC. We will replace this with a fully concurrent non-moving GC in a future version.

4. SQL integration.

   The current version only supports PostgreSQL. The available SQL constructs are also limited. In future version, we shall support fuller SQL syntax and multiple servers including MySQL.

5. Target Architecture.

   The current compiler only generates IA-32 code. We plan to replace our current backend with a multi-target one.

6. Interactive loop on Windows Systems.

   SML# realizes interactive loop by (1) compiling the input to an object file, (2) linking with the currently running system to generate a dynamically loadable file, and then (3) dynamically loading the object code using dlopen. In Windows systems, performing the linking in step 2 requires to specify a link information file for each of all the previous object files. This implies that the command-line arguments to SML# compiler uses in step 2 keep increasing during the interactive session, and will hit the limit of the command-line length. At that point, the interactive session may stall.