Alice's component system has a lot in common with that of Oz. As described in the interoperability document, Alice components are actually mapped to Oz functors. However, we want to bring a number of differences to the attention of the prospective Alice user who knows Oz.
Just like Oz, Alice uses resolvers to locate resources. In particular, localizing of components and pickles is performed under a resolver. Where Oz initializes this resolver from the value of the OZ_LOAD environment variable, Alice uses the environment variables ALICE_LOAD_PREFIX and ALICE_LOAD_SUFFIX instead.
alicerun initializes OZ_LOAD, unless set, in the same way that ozengine does. Alice's resolving methods are defined as follows:
If ALICE_LOAD_PREFIX is set, its methods are tried before any of the following.
If the URL uses the x-oz scheme, it is tried as-is, for compatibility with Oz.
Otherwise, the URL is tried with the platform's default component extension appended, which is .ozf.
If that fails, the URL is tried as-is, for compatibility with Oz.
If that fails, and ALICE_LOAD_SUFFIX is set, its methods are tried at this point.
Alice provides component managers, which are similar to Oz module managers. However, they have distinct implementations and may behave differently.
Alice component managers do perform type-checking at link time, as opposed to Oz module managers.
The fact that a component is native is not indicated, as in Oz, by the {native} annotation of the component's URL. Instead, the localized file is inspected to determine whether it is a pickled component or a native component and linked accordingly.
Exceptions raised during evaluation of components are wrapped inside a Component.Failure exception. Oz module managers just propagate the exception as-is to all clients.
Alice provides its own command-line tool alicerun to run applications as a replacement to ozengine provided by Oz. Both perform the same tasks of determining the installation directories, initializing environment variables, and launching the virtual machine to evaluate the component whose URL is given on the command line, along with further command line arguments.
There are, of course, a number of differences. ozengine uses an Oz module manager, using the OZ_LOAD resolver, while alicerun uses an Alice component manager, using the ALICE_LOAD resolver. Because Alice component managers can link Oz functors, Oz applications can be started by alicerun without any change. The converse, running Alice applications using ozengine, however requires the OZ_LOAD environment variable to be set to include all resolving methods enumerated above for ALICE_LOAD. Note that this loses link-time type-checking however.
Alice uses its own alicelink tool as a replacement for ozl. The tools differ in their behaviour as follows.
alicelink uses the ALICE_LOAD resolver instead of the OZ_LOAD resolver, with all the implications detailed above.
alicelink does not include any components by default. In particular, you need to explicitly specify an --include option for the root component.
alicelink does not support anything similar to ozl's --relative option (which is ozl's default behaviour). Resolved URLs may have to be made relative using explicit --rewrite options instead.
Rewriting in alicelink is more general. It is based on patterns as defined by resolving instead of prefix replacement. Accordingly, you need to use --rewrite from?{x}=to?{x} instead of --rewrite from=to to achieve the same effect as ozl. (Note that prefix matching as performed by --include and --exlude is not affected by this.)
Native components are not automatically excluded. They need to be explicitly exluded using --exclude options.
Linked functors produced by ozl always evaluate all contained functors directly, either concurrently (one thread is started per functor) or sequentially (in case there are no cyclic dependencies, in an order consistent with topological dependencies). In contrast, alicelink retains the same lazy evaluation order as the non-statically linked version.
A close approximation for
ozl Foo.ozf -o LinkedFoo.ozf
would be
alicelink ./Foo --include ./ -o LinkedFoo.ozf
As described above, the Alice resolver for components specified by ALICE_LOAD appends file extensions. This is because in Alice, file extensions should always be omitted in component URLs such as in import announcements. This is in contrast to Oz, which requires them. Alice deviates from Oz for improved cross-platform compatibility. The upcoming virtual machine for Alice uses a different file extension.
Abstract types in components carry strong identities. Consequently, clients require recompilation when the definition of an abstract type they use is recompiled. This is different from Oz, where a recompiled functor remains compatible to the previous compiled functor.
alicec does not support cyclic imports, as opposed to Oz. Alice component managers and the Alice static linker can handle cyclic imports, however. You can implement cyclic Alice components using tricks. This is not recommended, however.
alicec and alicelink do not yet implement an option to create executable compiled components as Oz does. The same effect can be achieved however by manually prepending a shell script or executable, as Oz does.