|
Mozart tools are not designed with any single methodology in mind. Rather, they focus on being able to correctly represent a very large set of concepts. They are not designed with a single environment or programming language in mind. Rather, they are programming-language agnostic to the maximum possible extent. They avoid the "kitchen sink" methodology, preferring to get power from cooperation.
Mozart gives programmers what the pipe gave to Unix shells: a simple and efficient way for different tools to cooperate and work together. This is what thin tools means: tools that are focused on a specific task.
Thin Tools and Concepts
Thin tools are important to enable Concept Programming. With monolithic development tools, you can only use whatever concepts the monolithic tool gives you. If you use Java, you can use objects, but not templates. If you use C++, you can use templates, but not garbage collection. All these tools have fixed semantics.
By contrast, thin tools give each other the capability to manipulate arbitrary concepts. In Mozart, thin tools work like compiler plug-in that can tailor larger tools to your exact needs. The heavyweight tools like XL can trim a lot of fat, while application-specific concepts can be developped.
The Mozart architecture is designed so that the same thin tool can be used in a variety of contexts:
Modifying Java using Thin Tools
Moka can invoke thin tools using a command line option that begins with a + sign. The option names the thin tool that must be invoked. The thin tool applies to the current program tree, and re-emits a modified program tree.
% moka tests/debug.java +strip:debug -out
The output of the previous command invokes the strip plug-in, which removes all declarations that begin with a given name ("debug" in the example). In other words, the plug-in modifies the Java program globally.
Thin Tools as XL Pragmas
The XL pragmas are designed to support external plug-ins. Therefore, you can invoke the plug-in on a local portion of an XL source file simply by prefixing the corresponding declaration or instruction with the name of the plug-in, followed by possible arguments.
The major difference compared to the Moka usage outlined above is that it doesn't apply to the whole source file, but only to the declaration or instruction which is tagged by the pragma, as illustrated by XL compiler test. The following code computes a symbolic differentiation in XL using the differentiation plug-in (NB: 'derivation' is the french word for 'differentiation', which I assumed translated as-is in english)
// REF=.ref
procedure Main is
with real Y := {derivation} dsin(X)/dX
Cascading thin-tools
Just like tools on the Unix command line can be chained in arbitrary number using pipes, thin-tools can be cascaded. For instance, to add tracing code after removing the debug code, one could use the tracer plug-in:
% moka tests/debug.java +strip:debug +tracer -out
In XL code, the same effect would be obtained by writing the pragmas in sequence:
// REF=.ref
{strip debug}{tracer} module VeryLargeModule with ...
Using Persistent Storage
Mozart features a persistent storage format, which can be used for more complex workflows. For instance, the previous strip + tracer sequence can also be written as:
% moka tests/debug.java -save file.melody
% ./plugins/strip.plugin file.melody debug
% ./plugins/tracer.plugin file.melody
% ./moka -load file.melody -out
In this model, a persistent Melody file named file.melody is used to store the program representation between invokation of the individual components.
Note: In the current implementation, this is actually what happens behind the scene when a + option is used with Moka. However, in the future, it is possible that the overhead of persistent storage might be avoided in that case. Using persistent storage might result in a performance loss for that future implementation.
| 