Frequently Asked Questions
What is the origin of the name "Alice"?
It is a reference to Lewis Caroll's "Alice in Wonderland". The name has been chosen to continue naming our languages after famous children's fantasy books, a tradition that has been started with Oz (of course, named after Frank Baum's "Wizard of Oz").
Previously, the code name for what now has become Alice was "Stockhausen", which in turn was in the tradition of naming our systems after famous composers. Mozart is quite baroque, and Stockhausen fit the bill for something more minimalistic and post-modern. You still might find some references to it.
Why did you develop a new language instead of concentrating on Oz?
Oz always has been a platform for experimental language design. Over the years many interesting features have been incorporated. The purpose of the Alice project is to take a second look at the ideas that proved to be most useful, and reconsider their design with emphasis on simplicity and safety. That required abandoning some of the basic design decisions of the Oz language.
We also hope that the familiar feel of a standard functional language attracts more people from other camps to the wonderful technology found in Alice and Mozart. For people already using Oz the Alice system is best seen as an additional tool they can use whenever appropriate, e.g. when they need better support for functional programming, or want to be backed up by a type system.
How compatible is Alice with SML?
Quite. See http://www.ps.uni-sb.de/alice/manual/incompatibilities.html for the list of deviations from the standard. Most SML code not using non-trivial sharing constraints should work out-of-the-box.
The main obstacle, though, is the way separate compilation works, which tends to be different on every SML system (because it is not defined by the standard). In Alice you need to put import announcements into your code. The compiler has some special support for making interoperability easy, see http://www.ps.uni-sb.de/alice/manual/compiler.html#interop.
What platforms does Alice support?
The SEAM-based version of Alice has been tested on Linux and Windows (x86 and x86-64), and on Mac Os (PPC and x86) so far, and to some extent even on a StrongARM PDA. In principle, the VM should be quite portable to other architectures, though just-in-time compilation will not be available on non-x86 architectures at the moment. Alice components themselves are completely platform-independent.
We currently provide only x86 packages as binaries, since the demand for other versions has been neglectable.
Why is Alice so slow?
It isn't :). Well, at least not once it's up and running. Start-up times are a known problem, particularly for large applications like the compiler or the interpreter. Execution speed itself is competetive with other VM-based systems. The Gecode constraint implementation actually outperforms all comparable libraries, even commercial ones.
Anyway, be assured that we are working on it.
Will there be a native code compiler for Alice?
Short answer: no. Platform-independent code is a central feature of the Alice design and can be achieved by using byte code only. Raw metal performance on the other hand has not been a goal.
But Alice actually employs just-in-time (JIT) compilation to native code (on x86 architectures). Apart from platform independence, jitting allows reflective optimizations dependent on dynamic information, which are important in the presence of futures and the highly dynamic linking model of Alice.
Have you considered porting Alice to VM xyz (e.g. JVM, LLVM, etc.)?
Yes. We do not think it is worthwhile. Porting to an existing VM usually is suggested for two reasons: ease of implementation and language interoperability. In our experience, neither materializes in practice.
The entire Alice architecture relies on two core technologies: futures and generic pickling. Both of these require pervasive support from the VM. They cannot be implemented easily nor efficiently on top of a conventional VM. That was the reason for us to start work on our own SEAM framework. (Not to mention common shortcomings like lack of tail calls or overly heavy object models in many cases.)
Over time, we already have developed four different backends for Alice: SEAM, Mozart, JVM and Dot-NET. The experimental ports to the JVM and to Dot-NET both required heavy encoding and thus were inefficient. Because of pervasive encoding, they did not deliver easy interoperability either. Even the initial implementation of Alice on the Mozart VM - a system that already has all the required features - did not provide smooth interoperability with Oz, due to subtle semantic mismatches.
These problems are not specific to Alice - other ports of foreign languages to existing VMs face similar problems, to different degrees. In general, efficient implemetation and language interoperability by use of a common VM is a much harder and more subtle problem than most people expect.
Where is the source code for the .alc files?
Compiled Alice ML components are platform-independent. We build them only once for all platforms and include the result in all distributions. Therefore, even the source distributions do not require actual ML source code, and consequently do not include them.
It is desirable to have the same builds for all platforms. Compiled components contain compile-time generated information (like type names), and we want to ensure that this is coherent across platforms for any given release of Alice ML. This simplifies dealing with bug reports, for example.
All sources are available from the CVS.